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ABSTB ACT 

This  thesis  is  intended  to  demonstrate  the  technological 
feasibility  of  interfacing  numerous  automated  information 
systems  throughout  the  joint  deployment  community.  Through 
the  use  of  the  EDI  concept,  deployment  information  can  be 
transferred  between  commands  which  must  interact  in  order  to 
efficiently  and  effectively  plan,  execute,  and  coordinate 
deployment  efforts.  The  Electronic  Data  Interchange  is  a 
transaction  set  oriented  interchange  which  provides  the 
means  for  efficient  data  communication.  Implementation  of 
the  EDI  concept  will  tie  together  systems  throughout  the 
community  in  support  of  the  Joint  Operation  Planning  and 
Execution  System  (JOPES)  .  '  ,  *  *  ^7 ;/  ’*• 
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I.  INTRODUCTION 


The  joint  deployment  commurity  is  dependent  upon  elec¬ 
tronic  exchange  of  data  for  successful  operations.  Current 
systems  do  not  provide  the  necessary  commands  the  ability  to 
communicate  quickly  and  efficiently,  causing  information 
exchange  delays  and  erroneous  or  out-of-date  data  to  be 
transmitted.  Both  planning  and  execution  phases  of  deploy¬ 
ment  operations  are  adversely  affected. 

The  Electronic  Data  Interchange  (EDI)  concept  has  been 
proposed  as  a  system  for  realizing  a  distributed  database 
approach  to  information  management,  the  approach  required  by 
the  Joint  Operation  Planning  and  Execution  System  (JOPES)  . 
The  EDI  concept  provides  a  means  for  electronic  interface 
among  commands  which  do  not  have  the  same  hardware,  soft¬ 
ware,  or  database  management  systems.  While  there  are  many 
factors  to  be  considered  when  implementing  a  community-wide 
system,  and  not  all  concerns  or  issues  can  be  addressed  by 
any  one  system,  perhaps  one  of  the  most  basic  issues  is  the 
feasibility  of  implementing  an  exchange  system  such  as  the 
EDI  system. 

This  thesis  demonstrates  the  feasibility  of  implementing 
the  EDI  concept  throughout  the  joint  deployment  community. 
It  also  describes  the  connection  between  service  unique 
systems  and  the  system  supporting  the  joint  deployment 
syst  em. 

Chapter  II  provides  background  by  defining  the  Joint 
Deployment  System.  Its  current  planning  and  execution 
systems  are  outlined.  The  EDI  concept  is  then  examined,  and 
its  applicability  tc  the  present  system  is  described. 
Chapter  III  examines  the  EDI  concept  in  depth.  The 
mechanics  of  the  system  are  explained,  and  a  generic 


description  of  how  such  an  interface  is  accomplished  is 
given.  Chapter  IV  contains  a  description  of  the  scenario 
and  data  elements  used  to  demonstrate  the  proposed  inter¬ 
change  system,  and  the  results  of  the  demonstration. 
Chapter  V  is  a  discussion  of  current  service  unique  systems 
which  exist  at  different  levels  through  the  joint  deployment 
community.  These  service  unique  systems  are  examined  with 
respect  to  their  interface,  both  current  and  potential,  with 
the  joint  deployment  system.  limitations  of  the  EDI  concept 
are  also  explored.  Chapter  VI  discusses  factors  which  must 
be  considered  when  implementing  this  system.  Implementation 
benefits  which  can  be  realized  through  the  use  of  the  EDI 
concept  are  then  summarized. 
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II.  BACKGROUND 


The  Joint  Deployment  system  (JDS)  "consists  of 
personnel/  procedures,  directives,  communication  systems, 
and  electronic  data  processing  systems  to  directly  support 
time-sensitive  planning  and  execution^  and  to  complement 
peacetime  deliberate  planning  1]  The  community 

which  is  directly  concerned  with  the  JDS  ranges  from  organi¬ 
zations  at  the  NCA  level  down  to  the  actual  deployable 
fighting  units.  The  amount  of  information  exchange  neces¬ 
sary  to  provide  all  concerned  with  appropriate,  timely,  and 
accurate  information  is  staggering. 

A.  PLANNING 

There  are  two  distinctly  separate  types  of  planning 
within  the  JDS.  The  Crisis  Action  System  (CAS)  is  concerned 
with  planning  under  time-sensitive  or  crisis  situations. 
Deliberate  planning  is  planning  during  peacetime,  non-crisis 
operations.  Planning  for  joint  military  operations  and 
force  deployment  is  conducted  using  the  Joint  Operations 
Planning  System  (JOPS).  JOPS  consists  of  policies,  proce¬ 
dures,  and  systems  used  to  support  force  deployment  plan¬ 
ning.  The  ADP  portion  of  JOES  operates  on  the  Worldwide 
Military  Command  and  Control  System  (WWMCCS)  computer 
system.  [  Ref.  2  ]. 

1 .  deliberate  Planning 

There  are  five  phases  to  deliberate  planning: 
initiation,  concept  development,  plan  development,  plan 
review,  and  supporting  plans.  These  phases  are  depicted  in 
Figure  2.1  [Ref.  3:  p.  5  1.  The  first  two  phases  are 


concerned  with  defining  the  threat  and  establishing  an 
appropriate  concept  of  operations.  The  third  phase,  plan 
development,  has  as  its  objective  a  "transportation 
feasible,  implementable  plan."  Daring  Phase  IV,  plan 
review,  the  plan  is  revised,  taking  into  account  adequacy, 
feasibility,  suitability,  and  the  dynamics  of  change.  An 
approved  plan  is  ultimately  produced.  Phase  V  produces  a 
family  cf  supporting  plans,  taking  into  consideration 
service  doctrine  and  support  agreements. 

The  primary  document  associated  with  deliberate 
planning  which  outlines  deployment  reguirements  is  the  time- 
phased  force  deployment  data  (TP FDD).  This  is  created 
during  the  Plan  Development  phase,  and  at  this  stage 
contains  the  information,  on  a  notional  basis,  needed  to 
describe  a  deployment. 

The  Transportation  Operating  Agencies  (TOAs)  are 
responsible  for  preparing  movement  schedules  which  support 
reguirements  established  by  the  TPFDD.  In  order  to  accom¬ 
plish  this,  the  TPFED  goes  through  an  extensive  refinement 
process,  with  actual  forces  identified  to  replace  the 
notional  forces.  Additionally,  specific  transportation 
requirements  and  unique  deployment  situations  are  identi¬ 
fied.  The  execution  feasibility  of  identified  scheduled 
movements  is  tested  by  the  appropriate  TOAs,  using  service 
unique  systems  and  software.  The  TPFDD  and  the  associated 
OPLAN  are  eventually  reviewed  and  approved  by  the  JCS,  and 
the  TPFDD  is  then  entered  into  the  deployment  data  base  at 
the  Joint  Deployment  Agency  (JDA) .  When  completed,  the 
TPFDD  contains  time-phased  force  data,  non- unit-relate d 
cargo  and  personnel  data,  and  transportation  data  for  the 
operation  plan,  including  supporting  units  with  associated 
priorities,  routing  of  forces  to  be  deployed,  associated 
mobility  data,  and  cargo  and  personnel  movements  to  be 
conducted  concurrently  with  the  deployment  of  forces. 
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Criteria:  The  Threat 

Planning  Tasks  and  Forces 

Objective:  To  Set  the  Stage 


Basis:  Mission  Assignment  (Forecast  Assignment 

Criteria:  Force  and  Resource  Allocation 

All  Significant  Factors 
Concept  Adequacy 
Objective:  Derive  the  Concept 
of  Operations 

Basis:  The  Commander's  Concept 

Criteria:  Force  and  Resource  Allocation 

Service  Planning  Factors 
Strategic  Movement  Data 
Objective:  A  Transportation  Feasible 
Implementable  Plan 

Basis:  The  Plan 

Criteria:  Adequacy  and  Feasibility 

The  Dynamics  of  Change 

Objective:  An  Approved  Plan 


Figure  2.1  Phases  of  Deliberate  Planning 


[Ref.  4]  This  refined  TPFDD  is  accessible  to  the  deployment 
community  and  can  be  updated,  tc  some  extent,  by  the  TOAs  as 
required.  Continual  interaction  between  J DA  and  the  TOAs, 
as  well  as  interaction  between  two  or  more  TOAs,  is  neces¬ 
sary  for  the  successful  refinement  of  the  TPFDD.  Various 
stages  of  refinement  require  interaction  at  conferences,  via 
telephone,  and  via  computer  systems  which  support  the  JOS. 
Cnee  the  TPFDD  is  established,  interaction  is  primarily 
through  the  computer  systems.  Efficient,  accurate  interac¬ 
tion  is  necessary  for  the  deployment  data  base  to  accurately 
reflect  troop/supply  movement,  as  well  as  changing  require¬ 
ments  cr  force  assignments. 

2 •  Crisis  Action  Planning 

The  Crisis  Action  System  provides  a  framework  within 
which  time-sensitive  planning  can  be  accomplished.  The 
procedures  are  intended  to  provide  each  level  of  command  the 
information  necessary  to  develop  timely  recommendations  to 
aid  the  NCA  in  making  decisions  involving  U.S.  military 
forces  in  the  execution  of  military  courses  of  action. 
[Ref.  5:  p.  II-1  ] 

There  are  six  phases  tc  the  crisis  action  system, 
which  are  outlined  in  Figure  2. 2.  Both  the  TOAs  and  JDA  are 
involved  immediately  in  any  crisis  action  planning.  During 
Phase  I,  the  joint  deployment  community  monitors  the  situ¬ 
ation,  as  JDA  ensures  that  the  joint  deployment  system  is 
operational.  During  Phase  II,  as  existing  OPLA Ns  are  being 
assessed  at  the  NCA  level,  the  crisis  action  teams  at  the 
TOAs  and  JDA  are  activated  and  plans  are  assessed  at  that 
level  as  well.  Coordination  between  the  CINCs  involved  and 
the  joint  deployment  community  also  takes  place.  During 
Phase  III  coordination  between  the  CINCs,  the  TOAs  and  JDA 
increases,  as  the  TOAs  prepare  preliminary  deployment  esti¬ 
mates  based  on  commanders1  estimates.  JDA  is  also  involved 


with  coordinating  the  estimates  from  the  TOAs  and  providing 
both  JCS  and  CINCs  with  the  consolidated  estimates. 
Throughout  the  execution  phases  the  TOAs  and  JDA  continue  to 
update  and  coordinate  the  force  deployment  data  base  as 
actual  movements  are  initiated  and  completed,  and  as 
requirements  change  during  the  conflict.  [Ref.  5:  pp.  11-2 
-  II-9] 

During  Phase  V  the  TOAs  begin  actual  scheduling, 
concentrating  on  the  first  six  days  for  air  and  the  first  30 
days  for  sea  transportation.  JDA  verifies  the  accuracy  of 
the  data  base  before  the  TOAs  begin  their  scheduling,  and 
resolves  transportation  problems  between  TOAs,  supporting 
and  supported  commanders.  During  Phase  VI  the  TOAs  and  JDA 
continue  to  manage  and  coordinate  transportation  require¬ 
ments,  respond  to  changes,  report  deployment  deviations  and 
diversions  in  JDS,  and  provide  deployment  status  to  those 
concerned,  from  the  TOA  level  tc  the  JCS. 

3.  Joint  Operation  Planning  and  Execution  System 

(JOPES! 

The  Joint  Operation  Planning  and  Execution  System 
(JOPES)  concept  was  approved  in  July  1983,  and  was  envi¬ 
sioned  as: 

the  foundation  for  cur  conventional  command  and  control 


in  peacetime  and  under  crisis  and  wartime  conditions. 
[Re!.  6:  p.  1] 


JOPES  came  into  being  primarily  because  of  the  extensive 
redundancy  of  JOPS  and  JDS.  Although  they  are  two  separate 
systems,  the  functions  and  products  of  each  are  so  entert- 
wined  that  neither  system  functions  efficiently  without 
considerable  interaction  with  the  other.  Although  not  yet 


fully  operational,  JOPSS  will  consist  "...of  the  policy, 
procedures,  software,  hardware,  personnel,  training,  and 
connectivity  necessary  to  facilitate  planning,  directing, 
coordinating,  monitoring  and  controlling  military  opera¬ 
tions."  [Ref.  7]  The  effective  implementation  of  such  a 
system  will  require  a  distributed  data  base  structure  within 
the  WWMCCS  community. 

B.  SERVICE  OHIQOE  AUTOMATED  SYSTEMS 

There  are  numerous  automated  systems  throughout  the 
services  which  are  related,  in  varying  degrees,  to  the 
deployment  community  as  a  whole,  and  to  the  joint  deployment 
system.  Figure  2.3  lists  some  of  these  systems,  and  indi¬ 
cates  their  interrelationships.  It  should  be  obvious  that 
an  interface  between  key  systems  involving  data  required  to 
effectively  plan  and  execute  force  deployment  would  greatly 
enhance  the  effectiveness  and  efficiency  of  such  operations. 
Although  not  as  clearly  indicated  in  Figure  2.3,  interfaces 
between  differing  commands  using  the  same  systems  frequently 
either  are  not  fully  automated,  or  have  inherent  serious 
time  delays  which  create  data  mismatches  and  inaccuracies. 

The  automated  systems  throughout  the  joint  deployment 
arena  are  constantly  changing  and  growing  to  meet  the  needs 
of  the  community.  Many  of  the  problems  identified  two  and 
three  years  ago  have  been  partially  or  completely  solved 
since  then.  There  are  still,  however,  significant  problems 
concerning  the  implementation  cf  required  interfaces.  As 
service-unicue  systems  proliferate,  interface  requirements 
become  both  more  numerous,  and  easier  to  accomplish.  For 
example,  as  a  system  which  automates  unit  requirements  data 
comes  on-line,  it  creates  a  need  for  an  interface  which  can 
provide  that  data,  in  required  format,  for  use  by  transpor¬ 
tation  agencies  within  the  deployment  community.  While  this 
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creates  a  need  for  an  interface,  it  also  simplifies  the 
problem  of  data  exchange,  as  automated  interfaces  are  faster 
and  easier  than  providing  that  same  data  manually  from  the 
original  data  location  to  the  lOAs  for  input  in  the  joint 
deployment  system. 

The  necessity  for  interfaces  between  appropriate  systems 
(and  appropriate  commands  withir  the  same  system)  is  widely 
recognized.  Implementation  on  a  significant  basis,  however, 
has  not  teen  accomplished. 

C.  E2ISTING  INTEBFACE  METHODS 

There  are  a  variety  of  methods  currently  in  use  for 
accomplishing  data  transfers.  For  those  organizations  not 
in  the  WWMCCS  Intercomputer  Network  (KIN)  ,  there  are  essen¬ 
tially  two  means  available  for  transmitting  information 
between  physically  separate  locations.  As  antiquated  as  it 
may  seem,  one  primary  method  is  the  use  of  the  U.S.  Postal 
Service.  In  numerous  instances,  actual  output  listings  from 
the  different  systems  are  mailed  to  the  units,  the  units 
make  pen  and  ink  changes  as  the  status  of  forces  and  equip¬ 
ment  changes,  then  the  listings  are  mailed  back  to  the 
computer  site  for  update  to  the  actual  file.  In  the 
interim,  continuous  telephone  communication  between  the 
parties  involved  helps  keep  the  files  from  becoming 
uselessly  out  of  date. 

In  other  cases,  the  existing  AUTODIN  is  used  to  provide 
either  tape-to-tape  or  card-to-card  transfer  of  data.  In 
either  instance,  when  AUTODIN  is  used  there  is  a  consider¬ 
able  human  interface  required  which  not  only  slows  the 
transfer  process  but  always  introduces  an  unnecessary  error 
factor. 

A  third,  significantly  more  efficient,  method  of  data 
transfer  in  use  today  is  the  WIN.  For  those  locations 


having  access  to  WIN  the  human  interface  is  minimized.  WIN 
not  only  allows  for  automatic  tape-to-tape  transfers  hut 
also  provides  a  means  of  computer-to-compu ter  disk  transfer. 
Disk-to-aisk  transfers  are  considerably  faster  and  more 
efficient  than  tape-to-tape.  Ihis  is  primarily  due  to  the 
sequential  nature  of  a  tape  transfer.  when  automatically 
sending  data  over  communications  lines,  there  is  always  the 
danger  of  a  break  in  communications  service,  a  ’timeout 
period'.  Under  the  present  WIN  system,  once  a  tape  transfer 
is  interrupted,  for  whatever  reason,  it  is  physically  impos¬ 
sible  to  restart  the  tape  at  some  point  in  the  middle.  This 
means  that  the  sending  tape  is  rewound  and  the  entire  tape 
retransmitted.  Tape-to-tape  transfers  are  an  all  too  common 
occurrence  in  interfacing  the  systems  within  the  WKilCCS 
today.  Although  WIN  disk-to-disk  transfers  are  considerably 
more  efficient,  the  present  need  for  standardization  of  both 
the  software  and  hardware  required  to  accomplish  the 
exchange  introduces  another  more  complicated  issue. 

D.  STANDARDIZATION 

One  of  the  methods  suggested  to  accomplish  the  necessary 
interchange  of  information  is  community- wide  standardiza¬ 
tion.  This  method  has  traditionally  been  used  in  the 
computer  industry,  for  several  reasons.  Initially,  this  was 
the  only  alternative  available;  technology  was  not  readily 
available  which  would  permit  any  meaningful  communication 
between  different  vendors'  equipment.  It  was  only  with  the 
advent  of  numerous  companies  and  systems  and  the  resulting 
profusion  of  previously  incompatible  equipment  that  efforts 
were  made  to  develop  methods  of  computer-to-computer 
communications. 

The  first  generation  of  interfaces  required  a  consider¬ 
able  amount  of  standardization.  Programs  which  translated 


from  one  system  to  a  totally  different  system  were  designed 
primarily  as  one-time  conversion  opportunities.  Whether  for 
technological  or  commercial  reasons,  standardization  was 
considered  necessary. 

The  next  stage  in  the  evolution  of  computer  communica¬ 
tions  involves  interfaces  that  eliminate  the  need  for  stan¬ 
dardization.  These  are,  however,  relatively  new,  and  are 
not  as  well  known  or  understood  as  standardization.  Perhaps 
because  of  this,  the  standardization  solution  to  the  data 
exchange  problem  throughout  the  joint  deployment  community, 
as  well  as  elsewhere,  has  been  proposed  by  many  concerned 
with  the  issue.  Certainly  standardization  of  data  elements 
and  format  (and  possible  hardware  as  well)  would  provide  the 
opportunity  for  automated  data  exchange.  Unfortunately, 
there  are  also  significant  drawbacks  to  standardization. 
The  most  obvious  may  be  that  the  joint  deployment  community 
already  abounds  with  quite  a  variety  of  "non-standard"  hard¬ 
ware  and  software.  The  conversion  in  equipment  costs  alone 
becomes  impractical.  Equally  as  important,  however,  is  one 
of  the  underlying  reasons  for  the  existence  of  the  differing 
software  and  hardware:  differing  applications  needs. 

The  commands  within  the  joint  deployment  community  are 
responsible  for  different  missions,  and  their  daily  require¬ 
ments  emphasize  different  aspects  of  the  deployment  picture. 
The  same  transaction  (e.  g.  ,  shipment  of  tanks  from  Ft.  Ord, 
California  to  Misawa,  Japan)  is  of  differing  importance  to 
different  levels  in  the  joint  deployment  community  (the 
initiating  unit,  the  Transportation  Operating  Agency 
involved,  the  unit  assigned  tc  carry  the  tanks,  and  the 
Joint  Deployment  Agency)  .  The  importance  of  individual  data 
elements  involved  in  this  transaction  vary  from  command  to 
command.  Additionally,  each  command  involved  has  ether 
reporting  requirements  within  its  own  service  which  require 
data  in  certain  format.  To  require  identical  data  element 


formats  and  transmission  structures  at  each  node  of  this 
transportation  operation  would  introduce  inefficiencies  on 
the  local  level.  That  is,  data  elements  either  not  neces¬ 
sary  or  formatted  differently  at  a  local  level  may,  for  the 
"good"  of  the  community,  become  leading  data  items  which 
must  be  formatted  and/or  transmitted  differently.  A  further 
complication  can  be  illustrated  when  items  as  simple  as  a 
shipping  date  are  standardized.  Different  commands  may 
organize  filing  or  retrieval  systems  by  day  or  month; 
requiring  every  command  in  the  joint  deployment  system  to 
place  the  day  first  introduces  unnecessary  confusion  at 
those  locations  where  other  daily  tasks  require  the  month 
first. 


E.  ELECTRONIC  DATA  INTERCHANGE  CONCEPT 

Electronic  Data  Interchange  (EDI)  is  a  computer- to- 
computer  data  exchange  system  designed  to  be  used  by  both 
industry  and  government.  The  EDI  system  objective  is  to 
develop  and  maintain  standards  for  the  electronic  inter¬ 
change  of  data  between  any  type  or  size  of  companies  or 
government  agencies.  These  standards  were  developed  in  a 
joint  industry/government  program  sponsored  by  the  United 
States  Department  of  Transportation.  In  order  to  accommo¬ 
date  the  requirements  of  the  majority  of  potential  users, 
the  Transportation  Data  Coordinating  Committee  (TDCC)  was 
assigned  the  task  of  establishing  and  maintaining  the  stan¬ 
dards.  TDCC  in  1985,  recognizing  that  potential  applica¬ 
tions  of  EDI  systems  were  not  limited  to  the  transportation 
industry,  changed  their  name  to  EDI  Association.  The  first 
set  of  EDI  standards,  published  in  1975,  coordinated  the 
requirements  of  ocean,  air,  motor,  and  rail  carriers.  In 
addition,  these  same  standards  were  designed  to  meet  the 
needs  of  the  users  of  the  carrier  services.  Subsequent 
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enhancements  have  been  made  to  the  EDI  standards  in  response 
to  reguests  from  the  user  community. 

The  EDI  software  uses  a  ’table-driven’  technique  to 
generalize  processing  regardless  of  the  application  being 
processed.  Specific  directions  are  taken  by  the  software 
depending  on  the  data  being  processed  and  the  particular 
tables  associated  with  the  applications.  The  EDI  software 
resides  in  each  participants’  computer  system  and  is  an 
interface  between  EDI  format  structures  and  the  partici¬ 
pant’s  internal  system.  The  EDI  software  assumes  that  an 
EDI  participant  already  has  an  automated  system  in  use  for 
processing  internal  applications.  Some  of  these  internal 
applications  require  data  from  external  (outside  the  partic¬ 
ipant's  system)  sources  or  provide  data  to  external  points. 
The  format  for  these  interagency  data  transfers  is  given  in 
the  EDI  standards.  EDI  is  not  an  independent  system  but  is 
meant  to  interface  existing  in-house  systems.  TDCC  EDI 
software  eases  the  transition  from  a  completely  closed 
internal  system  to  an  internal  system  with  a  controlled 
external  interface.  [Ref.  8] 

EDI#  Incorporated  is  a  company  independent  of  the  TDCC 
with  a  staff  which  works  as  systems  consultants  to  TDCC  and 
has  comprehensive  and  detailed  knowledge  of  the  EDI  stan¬ 
dards  and  the  TDCC  software.  EDI,  INC.  has  performed  a 
significant  role  in  the  industry-wide  acceptance  of  the  EDI 
standards  as  a  viable  means  of  data  interchange.  This 
company/  under  contract,  designed  the  software  to  link  users 
in  the  grocery  industry,  the  transportation  industry,  and  is 
currently  under  contract  with  the  Military  Sealift  Command 
and  the  Military  Traffic  Manageaent  Command. 

The  emphasis  of  the  EDI  concept  is  on  the  exchange  of 
information  between  computers  through  the  use  of  standard 
transaction  sets.  This  provides  one  of  the  major  benefits 
of  such  a  system:  the  users  preserve  their  autonomy  while 


efficiently  interfacing  with  ether  users.  There  is  no 
requirement  for  different  users  to  use  the  same  hardware, 
software,  or  even  data  base  management  systems.  This  also 
provides  the  additional  benefit  of  being  able  to  add  or 
delete  individual  data  elements  without  requiring  software 
logic  changes.  £Ref.  7:  p.  42] 

The  EDI  interface  creates  a  data  exchange  structure  in 
the  format  depicted  in  Figure  2.4.  With  this  structure 
modifications  to  one  user's  applications  do  not  affect  other 
users.  The  interface  software  is  between  the  individual 
user  and  the  standard  data  set.  Once  all  nodes  of  the 
structure  can  interface  with  the  standard,  data  exchange  can 
be  accomplished  between  any  two  nodes,  with  no  additional 
interface  requirements  necessary  for  communication  between 
the  two  nodes.  The  interface  acts  as  a  transparent  partner; 
from  the  user's  viewpoint  the  communication  is  directly  with 
the  second  user.  The  overall  number  of  interfaces  required 
for  communication  between  all  nodes  is  therefore  reduced  (to 
four  in  the  example  in  Figure  2.4  from  six  if  the  standard 
transaction  set  was  not  available).  [Bef.  7:  p.  34] 


Figure  2.4  Interfacing  Through  a  Standard  Data  Set 


23 


F.  SUMMARY 


It  should  be  apparent  that  the  flow  of  information 
between  relevant  commands  during  both  deliberate  planning 
and  crisis  actions  must  be  timely  and  accurate.  The  data 
base  required  to  support  such  planning  and  execution  must  be 
accessible  to  all  involved,  and  must  be  kept  current.  Thus, 
effective  interchange  of  information  necessitates  a  network 
which  is,  as  much  as  possible,  automated,  easy  to  use  at 
each  node,  and  reliable.  The  EDI  concept  is  one  proposal 
available  to  accomplish  this  interchange.  The  resulting 
network  should  encompass  service  unique  automated  systems  as 
well  as  the  specific  computer  system  supporting  JDS. 
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III.  ELECTRONIC  DATA  INTERCHANGE 


A.  INTRODUCTION 


Data  interchange  is  concerned  with  the  transmission  and 
interpretation  of  information  among  participants.  The 
proposed  EDI  interface  is  a  computer-to-computer  lata 
exchange  system  which  utilizes  a  disk-to-disk  transfer.  Its 
purpose  is  to  simplify  the  integration  of  external  communi¬ 
cations  with  internal  applications  programs.  The  previous 
chapter  introduced  the  EDI  concept;  this  chapter  will 
describe  in  some  detail  the  mechanics  of  the  interchange 
system.  Areas  of  importance  include  the  EDI  software  and 
the  data  and  format  structures.  Definitions  of  concepts 
which  are  integral  to  an  understanding  of  the  following 
discussion  are: 

Interface  System:  Interface  system  refers  to  the 

compuTer  programs  to  be  used  to  construct  or  edit  infor¬ 
mation  communicated  between  electronic  data  interchange 
systems  and  the  internal  applications  programs  of  a 
participant. 


Electronic  Data  Interchange:  Electronic  data  inter- 
cKange  means  £Ee  transmission  of  transaction  data,  in 
formats  selected  in  the  EDI  standards,  between  two  or 
more  companies  or  organizations  having  business  rela¬ 
tionships. 


I nternal  Applications:  Internal  applications  refers  to 
EEe  use  of  electronic  data  processing  equipment  to 
support  internal  operational  information  functions.  The 
electronic  data  interchange  system  interfaces  with  tut 
does  not  include  internal  applications.  [Ref.  9] 


It  must  be  emphasized  that  the  EDI  concept  represents  an 
interface  between  existing  internal  automated  systems  and 
external  automated  systems.  It  supplements  existing  systems 
in  that  data  transfer  and  communication  are  enhanced.  The 
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EDI  system  does  not  provide  internal  data  manipulation  capa¬ 
bilities,  nor  will  it  (of  itself)  produce  such  things  as 
reports,  data  summaries,  or  OPLANs. 

E.  EDI  SOFTWARE 

The  EDI  software  resides  in  each  command’s  computer 
system,  and  provides  an  interface  between  that  system  and 
EDI  format  structures.  This  software  extracts  data  from  an 
internal  system’s  automated  data  base  for  transmission  to 
other  commands.  When  receiving  data  from  other  commands, 
the  same  software  puts  information  into  the  data  base. 
Objectives  for  the  EDI  software  are: 

To  automatically  generate  and  interpret  data 
To  process  transaction  sets. 

To  ensure  common  interpretation  of  transmission  by  both 
the  sender  and  receiver. 

To  code  information  when  practicable. 

To  use  fixed  format  standards. 

To  eliminate  data  net  likely  to  be  used. 

To  allow  for  flexibility  so  that  the  standards  may  be 
enhanced  as  needs  change  or  evolve.  [ Hef .  9:  pp.  2-3] 

1 .  Sof twar e  Operation 

The  key  to  EDI  software  operation  is  its  method  of 
transmission.  The  reguired  data  is  first  transformed  into 
EDI  transaction  sets,  then  transmitted  in  standard, 
compressed  format.  Upon  receiving  a  transmission,  the  soft¬ 
ware  ’explodes’  the  compressed  data  into  fixed  format 
records  defined  by  the  receiving  user  which  are  compatible 
with  the  user’s  internal  software  and  database.  The  order 
of  elements  in  a  given  user’s  record  structure  does  not  have 
to  be  the  same  as  that  used  by  the  EDI  software.  Software 


procedures  and  interfaces  rearrange  the  data  as  necessary. 
The  EDI  software  uses  a  column  of  information  in  one  of  the 
EDI  tables  (Table  4,  explained  below)  in  order  to  ’under¬ 
stand'  the  locations  cf  given  data  elements.  The  interfaces 
between  EDI  software  and  the  user's  overall  system  are 
diagrammed  in  Figure  3. 1  Those  modules  within  the  dark  box 
make  up  the  EDI  software.  [Ref.  9:  p.  28]. 

2 .  Tables 

To  facilitate  change  and  modification,  the  EDI  soft¬ 
ware  is  'table-driven'.  The  tables  define  formats  and  edit 
parameters  for  use  by  the  program.  The  five  tables  used  by 
the  EDI  software  are  as  follows: 

Table  1:  Set  Pointers 

Table  2:  Segments  for  Each  Transaction  Set 
Table  3:  Segment  Pointers 
Table  4:  Data  Elements  for  Each  Segment 
Table  5:  Data  Elements  [Ref.  9:  pp.  43-44] 

Their  functions  are  described  in  Figure  3.2  [Sef.  9:  p.  35]. 
The  same  five  tables  used  for  generation  of  data  to  be 
transmitted  are  used  for  interpretation  of  received  data. 
The  software  programs  maintain  pointers  to  the  tables. 
These  pointers  are  moved  as  necessary  during  processing  in 
order  to  edit  or  generate  data  formats. 

3.  Software  Programs 

There  are  two  EDI  operational  software  programs: 
Set  Generator  for  transmission  and  Set  Interpreter  and 
Parser  for  reception.  These  programs,  in  addition  to  main¬ 
taining  table  pointers,  use  the  information  at  the  pointer 
locations  in  conjunction  with  information  from  the  internal 
data  base  to  assure  program  operation  and  interpretation  of 
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Figure  3.  1  Data  Interchange  Program  Modules 

data.  The  Set  Generator,  using  the  above  information 
composes  transaction  sets  in  proper  transmission  structure 
The  Parser  extracts  data  elements  from  the  continuous  strea 
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Figure  3.2  The  Five  EDI  Tables 


of  characters  received,  and  forwards  the  data  to  the  Set 
Interpreter.  The  Set  Interpreter  edits  incoming  transaction 
sets.  The  resulting  data  is  passed  to  the  internal  applica¬ 
tions  routine. 

C.  EDI  DATA  AND  FOBHAT  STBOCTOEE 

1 .  Data  Dictionary 

All  EDI  system  transaction  segments  and  transaction 
sets  are  constructed  from  basic  building  blocks  which  are 
contained  in  the  Data  Dictionary.  Within  this  'dictionary', 
all  data  elements  are  defined  in  a  standardized  format. 
This  does  not  indicate  a  need  for  standardization  among 
commands,  however.  The  internal  systems  used  by  commands 
will  interface  with  this  'centralized'  standard  through  the 
interchange.  The  data  dictionary  includes  the  following: 

-  Data  Element  Number 

-  Data  Element  Name 

-  Data  Element  Description 

-  Field  Length 

-  Characteristics 

-  Reference  Designators  [fief.  10:  p.  153] 

Appendix  A  is  an  example  of  part  of  a  data  element 
dictionary.  The  first  five  items  above  are  self- 
explanatory;  the  reference  designators  refer  to  the  trans¬ 
action  sets  in  which  the  particular  element  is  used. 

2.  Units  of  Information 

Ihere  are  three  basic  units  of  information  used  in 
the  EDI  data  interchange.  These  units  may  be  of  variable 
length  and  relate  to  each  other  as  shown  in  Figure  3.3 

[fief.  10:  p.  5]. 
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KDI  Information  flnits 


They  are  defined  as  fellows: 


Data  Element:  The  smallest  information  unit  in  the  EDI 
Ini ormaYIon  structure  is  the  data  element.  A  data 
element  may  be  a  single  character  code,  a  series  of 
characters  constituting  a  literal  description  or  a 
numeric  quantity. 

Data  Segment :  A  data  segment  is  composed  of  a  function 
Icientlrier  “and  one  or  more  functionally  related  data 
elements  positioned  serially  in  a  standard  manner. 


Transaction  Set:  A  transaction  set  is  that  group  of 
stanHard  data  segments,  in  a  predefined  sequence,  needed 
to  provide  all  of  the  data  required  to  define  a  complete 
transaction  such  as  purchase  order,  invoice,  bill  of 
lading,  or  freight  till.  [Ref.  9:  pp.  4-6] 

Additionally,  transaction  sets  are  grouped  into  functional 
groups,  which  are  combined  for  transmissions.  Appropriate 
segments  are  inserted  throughout  these  levels  in  order  to 
ensure  communication  coherency.  These  additional  units  are 
called  format  units  and  are  located  at  the  beginning  and 
ending  of  segments,  as  shown  in  Figure  3.4  [Ref.  9:  p.  7] 
Except  where  noted,  these  segments  are  required.  Although 
not  pictured,  there  are  also  format  units  at  the  data 
segment  and  data  element  levels. 

Each  data  segment  begins  with  a  unique  '  data  segment 
identifier'  and  ends  with  a  'data  segment  terminator'.  The 
first  is  composed  of  alpha/numeric  characters,  while  the 
latter  is  either  an  EBCDIC  cede  or  ASCII  code  character 
[Ref.  9;  p.  6].  At  the  data  element  level  the  format  unit 
is  known  as  a  'data  element  delimiter',  and  is  represented 
by  an  It  follows  each  data  element  in  a  segment  except 
the  last  (it  also  fellows  the  segment  identifier).  The 
asterisk  is  also  transmitted  whenever  there  is  no  data  being 
transmitted  for  a  defined  element  other  than  the  last 
element  in  a  segment.  This  preserves  the  data  element 
count.  The  information  required  to  completely  describe  a 
data  segment  is  depicted  in  Figure  3.5. 
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1  -  Set  Identifier 

2-  Reference  designator:  Segment  identifier  followed 
by  sequence  number  within  segment 

3  -  (A)  Alpha;  (N)  Numeric;  (AN)  Alpha/Numeric; 

(Dn)  Implied  Decimal  (with  n  places  to  right 
of  implied  decimal  point),  (R)  Decimal  (with 
decimal  point  explicitly  required),  (NZ)  Numeric— zero 

4  -  Data  element  name 

5  -  Mimmum/rnaximum  number  of  characters 

6—  Data  element  reference  number 

7—  New  line  character  or  carriage  return,  line  feed 

8-  (M)  Mandatory;  (C)  Conditional;  (0)  Optional 

9-  Special  relational  conditions 
10  -  Delimiter 
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Figure  3.5  Transaction  Segment  Format 

3.  Communicant  ions  Interface 

Ihe  EDI  software  utilizes  512  character  blocks. 
Existing  communications  may  utilize  blocks  of  other  lengths. 
There  is  no  need  to  change  either  the  EDI  software  or  the 
length  required  for  the  comnunications  protocol.  Ihe 


communications  software  used  should  adapt  to  both  lengths, 
as  indicated  in  Figure  3.6  [Ref.  9:  pp.  42,  44]. 
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Figure  3.6  Communications  Interface 


The  EDI  concept  provides  an  interchange  between  auto¬ 
mated  systems  internal  and  external  to  a  command  or  organi¬ 
zation.  The  software  resides  within  a  command’s  system,  and 
uses  a  table-driven  technique  to  allow  for  generalized 
processing,  regardless  of  the  application  being  processed . 
It  is  generic  in  that  no  specific  hardware  or  software  is 
required,  and  in  fact  many  different  vendors  may  be  used 
with  no  degradation  in  system  capabilities. 

Within  the  EDI  software,  data  elements,  data  segments, 
and  transaction  sets  are  used  to  convert  differing  formats 
to  standardized  format  for  transmission,  and  again  at  the 
receiving  end  to  reconstitute  the  transmission  into  formats 
acceptable  to  the  receiver.  As  should  be  obvious  after  the 
generic  description  of  the  software  mechanics  throughout 
this  chapter,  this  concept  is  applicable  at  many  different 
levels  throughout  the  joint  deployment  community,  as  well  as 
elsewhere  in  DOD. 


IV.  DEMONSTRATION 


A.  INTRODUCTION 

As  discussed  in  Chapter  II,  the  joint  operation  planning 
procedure  is  an  ongoing,  day-to-day  process.  Operation 
Plans  (OPLANs)  are  continuously  being  developed  and  revised 
to  ensure  there  is  an  OPLAN  designed  to  meet  any  anticipated 
contingency.  An  integral  part  cf  every  OPLAN  is  identifica¬ 
tion  of  those  military  units  required  to  implement  the  given 
plan.  Once  specific  units  are  identified,  the  Joint 
Deployment  System  comes  into  play  in  determining  the  trans¬ 
portation  assets  needed  to  deploy  those  units  to  the  oper¬ 
ating  location.  This  process  is  also  an  ongoing,  continuous 
procedure.  As  OPLANs  are  revised,  the  transportation  needs 
may  change;  as  units  acquire  new  equipment  or  modify  the 
old,  their  transportation  needs,  again,  may  change. 

In  order  to  ensure  that  the  transportation  assets  are 
available  to  fulfill  the  requirements  of  any  OPLAN,  the 
Joint  Deployment  Agency,  as  part  of  the  JDS,  maintains  a 
central  data  base  containing  all  of  the  specific  information 
regarding  the  deployment  needs  cf  every  military  unit.  This 
is  necessarily  a  very  large,  complex  data  base  and  it  is 
easy  to  visualize  the  tremendous  task  involved  in  keeping 
the  data  current  and  accurate.  The  specific  procedures 
employed  to  modify  and  update  this  data  base  vary  depending 
on  the  unit,  the  service,  and  TCA  involved  in  the  particular 
scenario.  In  any  case,  the  applicability  of  an  automated 
interface  between  JDS  and  the  organization  involved  in  the 
data  update  process  is  obvious. 

For  the  purpose  of  demonstrating  the  feasibility  of 
using  the  EDI  system  of  data  interchange  in  the  deployment 
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arena,  we  developed  a  scenario  involving  one  unit,  one  TOA , 
one  command  headquarters,  and  the  JDA.  It  is  important  to 
remember  that  what  we  are  demonstrating  is  only  one  very 
small  portion  of  the  overall  communications  process  and  data 
transfer  which  transpires  routinely  in  maintaining  the  JDS 
data  tase. 

In  this  scenario  development,  we  will  first  identify  the 
agencies  selected  to  exemplify  the  'typical'  data  flow,  then 
discuss  how  these  agencies  are  currently  accomplishing  the 
task  of  maintaining  the  data  on  a  daily  basis,  and  then  pose 
a  crisis  situation  which  requires  that  the  actual  system  be 
forced  into  action.  Finally,  we  will  show  an  example  of  the 
same  automated  systems  interfaced  using  EDI  as  compared  with 
the  current  procedures. 

B.  SCENARIO 

We  selected  the  Army's  Military  Traffic  Management 
Command  (MTMC)  as  the  TOA  involved  in  the  transport  of  the 
deploying  unit.  In  particular,  we  selected  the  7th  Infantry 
Division  out  of  Ft.  Ord,  CA  as  the  unit  to  be  deployed.  The 
geographical  location  of  Ft.  Ord  requires  transport  of  the 
unit  through  MTMC  Western  Area  (MTMCWA)  in  Oakland,  CA . 
Because  we  are  dealing  with  an  Army  unit,  the  Forces  Command 
(FORSCOM)  in  Atlanta,  GA  also  becomes  a  player.  And,  of 
course,  the  goal  of  our  scenario  is  to  show  how  each  of 
these  organizations  interfaces  with  the  Joint  Deployment 
Agency  and  the  JDS  in  Tampa,  FI. 

Each  of  the  above  organizations  uses  a  number  of 
different  automated  systems  for  managing  their  assets.  In 
this  demonstration  we  will  deal  only  with  FORSCOM 's  COMPASS 
which  produces  the  Automated  Unit  Equipment  List  (AUEL) ,  and 
MTMC  ’  s  SPUR.  The  current  procedures  require  the  following 


The  unit/  here  7th  Infantry  Division/  receives  a  copy 
of  its  ACJSL  from  the  COMPASS.  The  Installation 
Transportation  Officer  (ITC)  ,  or  his  staff,  reviews  the 
AUEL  and  periodically  submits  any  updated  information 
about  7th  ID's  equipment  tc  FORSCOM. 

FCRSCOM  maintains  the  accurate  status  of  each  unit's 
equipment.  Section  D  of  this  chapter  contains  examples 
of  the  types  of  information  maintained  in  the  COMPASS 
data  base. 

FCRSCOM  creates  a  tape  for  transfer  to  JDS,  with  the 
entire  description  of  each  unit's  equipment. 

JDA  updates  the  Unit  Movement  Data  (UMD)  file  in  JDS 
from  the  tape  transferred  from  FORSCOM.  Section  D 
contains  examples  of  the  t^pes  of  data  in  the  UMD . 
FCRSCOM  creates  a  second  tape  for  transfer  to  MTMC 
Headquarters  in  Washington,  D.C.  This  tape  contains 
the  same  basic  information  about  unit  equipment  as  that 
sent  to  JDA. 

MTMC  Headquarters  manually  extracts  classified  data 
from  the  COMPASS  tape  and  forwards  an  edited,  unclassi¬ 
fied  version  of  the  tape  tc  MTMCWA . 

MTMCWA  receives  the  tape  from  Headquarters  and  inputs 
the  data  into  the  System  for  Predetermining  Unit 
Requirements  (SPDRs)  .  SPURS  is  the  on-line  system  that 
is  used  by  the  TOAs  to  schedule  and  manifest  7th  ID  on 
a  particular  vessel. 

At  the  time  7th  ID  is  manifested,  MTMCWA  must  interface 
with  JDS  to  reflect  the  manifest  information  in  that 
data  base.  It  is  the  JDS  which  will  be  used  by  all 
other  participants  in  the  successful  deployment  of  7th 
ID.  For  instance,  the  Military  Airlift  Command  (MAC) 
mc.y  also  provide  air  assets  for  equipment  and  troop 
deployment. 


The  major  assumption  in  this  process  is  that  all  three 
organizations  and  their  associated  data  bases;  MTMCEA  in  the 
SPURS,  FCRSCOM  in  the  COMPASS,  and  J DA  in  the  JDS,  will  all 
have  the  exact  information  regarding  7th  ID’s  equipment  and 
transportation  requirements.  This  assumption  personifies 
the  major  flaw  in  the  existing  system.  Because  of  the  human 
intervention  required  to  extract  classified  portions  of  the 
data  and  the  amount  of  time  involved  to  accomplish  tape  to 
tape  transfers,  whether  using  AUIODIN  or  WIN,  there  are 
often  significant  differences  ir  these  three  data  bases.  It 
is  essential  that  MTMCWA,  where  the  unit  is  actually  mani¬ 
fested,  has  the  most  accurate  information  at  all  times.  It 
is  just  as  important  that  JDA,  as  the  coordinator  of  the 
overall  deployment,  not  limited  to  7th  ID,  also  have  the 
most  accurate  information. 

In  an  attempt  to  stay  current,  the  users  of  the  SPURs 
maintain  an  off-line,  but  direct,  communication  with  ail  of 
the  units  under  its  responsibility.  This  direct  correspon¬ 
dence  serves  the  purpose  of  data  currency  but  tends  to 
further  complicate  the  situatior..  Upon  receipt  of  unit  data 
through  the  COMPASS  to  SPURs  interface,  the  MTMCKA  transpor¬ 
tation  specialist  must  ascertain  whether  this  data,  or  that 
which  he  received  direct  from  the  unit,  is  the  correct 
information. 

C.  INTERACTION  DURING  CRISIS  DEPLOYMENT 

In  the  previous  section  we  discussed  the  daily  interac¬ 
tions  between  four  particular  nodes  in  the  overall  deploy¬ 
ment  process.  The  procedures  outlined  in  Section  B  are 
routinely  accomplished  without  the  added  complications  cf  an 
actual  crisis  situation.  Obviously,  when  a  crisis  does 
occur,  some  of  these  procedures  will  be  eliminated  while  the 
time  constraint  on  others  will  be  greatly  accelerated.  A 


simple  example  of  how  an  actual  crisis  operation  might 
develop  is  described  telow. 

•  First,  we'll  assume  a  crisis  situation  emerges  some¬ 

where  in  the  Pacific  Theater.  This  implies  that 
CINCPAC  becomes  both  the  unified  and  the  supported 
commander.  For  the  purpose  of  this  discussion  we  will 
also  assume  that  both  MAC  and  MTMC  are  involved  as  TOAs 
responsible  for  troop  and  equipment  deployment. 

However,  we  will  discuss  only  MTMC's  deployment  role. 
It  is  very  important  to  remember  the  significant  role 
MAC  would  also  be  playing  during  the  overall  data 
exchange  process. 

•  As  the  crisis  develops  there  is  constant  communication 
and  coordination  throughout  the  entire  military  commu¬ 
nity.  CINCPAC  submits  a  Commander's  Assessment  to  the 
Joint  Chiefs  of  Staff.  This  report  outlines  what 
forces  he  has  readily  available,  the  major  constraints 


to  the1'*-  employment,  and  his  proposed  course  of  action. 
JCS  reviews  the  situation  with  the  services  and  TOAs. 
The  NC A  is  continually  kept  informed  by  the  JCS  and 
through  the  WWMCCS  communication  systems.  Throughout 
this  process  the  JDS  data  base  is  accessed  to  provide 
the  latest  information  regarding  major  unit  force 
strengths  and  their  transportation  requirements. 
[Ref.  3:  p.  10] 

Eventually,  as  the  situation  progresses,  JCS  issues  a 
Warning  Order  containing  guidance  from  the  NC A 
pertaining  to  the  crisis.  Based  on  the  Warning  Order, 
another  round  of  communications  between  CINCPAC,  the 
service  components,  the  supporting  commanders,  and  the 
TOAs  transpires.  The  result  of  all  this  effort,  with 
again  significant  references  to  the  JDS  data  base  for 
supporting  data,  is  the  selection  of  a  specific  Course 
of  Action  (COA) .  [Ref.  3:  p.  10] 
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•  Tne  JCS  recommend  this  COA  to  the  Secretary  of  Defense 
and  the  President.  If  the  President  decides  to  proceed 
with  the  COA  involving  military  forces,  the  JCS  issues 
an  Alert  Order  to  CINCPAC.  In  response  to  the  Alert 
Order,  the  supporting  commands  and  TOAs  prepare  an 
Operation  Order.  The  JDA  assists  this  process  by: 


"...updating  the  force  list  and  coordinating  the  deploy¬ 
ment  of  schedules  by  the  transportation  operating  agen¬ 
cies.  The  deployment  data  base  at  the  Joint  Deployment 
Agency  constitutes  the  authoritative’,  up-to-date  source 
or  force  and  resupply  information.  The  data  base  can  be 
queried  by  the  entire  deployment  community  using  WIN." 
[Ref.  3:  p.  12  ] 


•  Finally,  if  the  President  decides  to  execute  the 
planned  operation,  the  Secretary  of  Defense,  through 
the  JCS  issues  an  Execute  Order  instructing  CINCPAC  to 
execute  his  Operation  Order.  This  begins  the  process 
of  deployment  execution. 

The  execution  phase  of  a  deployment  operation  reguires 
constant  contact  and  coordination  by  all  supporting 
commanders  and  TOAs,  in  our  case  FORSCOM  and  E1TMC.  In  actu¬ 
ality,  the  7th  Infantry  Division  would  have  been  identified 
as  a  proposed  supporting  unit  during  the  process  of 
selecting  the  appropriate  course  of  action.  With  even  the 
possibility  of  using  7th  ID,  FORSCOM  would  have  notified 
that  commander,  reguested  updated  AUEL  information  and 
forwarded  the  current  status  of  7th  ID  troops  and  equipment, 
along  with  their  transportation  reguirements,  to  the  JDS. 
All  of  the  information  must  be  available  prior  to  the  actual 
COA  selection. 

Once  7th  ID  is  officially  notified  of  the  order  to 
deploy,  the  transportation  process  is  activated.  HTMCKA 
begins  arrangements  for  ship  moveme’  L  of  heavy  equipment  to 
the  nearest  port  to  the  scene  of  the  crisis.  In  this 
instance,  7th  ID  departs  from  Oakland,  CA,  the  Pert  of 


WftWW.,fhWWWiT/(VTt'1V*>.Tl,WllS-«V«»>W 


Embarkation  (POE)  and  will  be  shipped  to  a  Port  of 
Debarkation  (POD)  somewhere  in  the  Pacific. 

The  actual  manifest  on  the  ship  is  accomplished  item  by 
item  as  the  equipment  and  supplies  are  loaded.  This  ensures 
an  accurate  account  of  the  exact  load  being  transported. 
This  exact  manifest  information  is  required  for  both  billing 
and  more  importantly,  for  proper  identification  at  the 
receiving  POD.  The  manifest  information  is  then  entered 
into  the  JDS  data  base  by  plans  personnel  on  site  at  MTMCWA 
in  Oakland.  It  is  obvious  that  these  individuals  must  have 
the  correct  data  pertaining  to  7th  ID's  deployment  to  the 
POD. 

This  marks  the  beginning  of  many  problems  which  arise  as 
a  result  of  the  data  transfer  procedures  discussed  in 
Section  E.  The  exact  manifest  information  is  known,  at  this 
point  in  time,  only  by  those  individuals  responsible  for  the 
actual  manifest  activity.  However,  when  this  data  is  loaded 
into  the  JDS  data  base,  the  JDS  system  often  rejects  the 
entry.  In  fact,  whenever  manifest  data  differs  in  any  way 
from  the  planned  equipment  lead  reflected  in  the  Unit 
Movement  Data  (U  MD)  file  maintained  in  JDS,  an  entry  error 
is  created.  This  data  rejection  causes  a  significant  time 
lag  in  the  effectiveness  of  the  overall  deployment  process. 

D.  DEMONSTRATION 

The  problems  arising  under  the  current  data  transfer 
procedures  can  be  significantly  reduced  through  the  applica¬ 
tion  of  the  EDI  concept.  The  use  of  EDI  for  one  of  the  data 
transfers  described  in  section  3  above  is  demonstrated 
below . 

Figure  4.1  is  a  copy  of  the  data  format  for  the  COMPASS 
Automated  Unit  Equipment  File  (AUEL).  Figure  4.2  is  a  copy 
of  the  data  format  for  the  Unit  Movement  Data  (UMD)  file  in 


JDS.  Appendix  B  is  the  EDI  transaction  set  which  would  be 
used  to  transfer  data  from  one  system  to  the  other.  The 
data  elements  which  are  required  for  transfer  between  the 
two  systems  are  indicated  by  the  alphabetic  characters  to 
the  left  of  the  data  element  name  in  Figures  4.1  and  4.2 
The  same  letters  (i.e.,  a,  b,  c,  etc.)  are  used  to  indicate 
the  same  item  of  data  within  each  file.  It  should 
be  noted  that  the  same  data  items  are  often  in  different 


locations  and  use  differing  field  lengths  in  each  system. 

Tracing  a  single  data  element  through  the  transmission 
process  should  illustrate  the  operation  of  the  EDI  method. 
Figure  4.3  contains  one  item  of  information,  as  shown  in  the 
AUEL  record  format  and  the  Automated  Unit  Equipment  listing. 
The  equivalent  data  element  in  EDI  format  is  also  shown,  as 
is  that  item  positioned  in  the  EDI  transmission  format.  The 
JDS  UMD  record  format  for  the  same  item  is  also  shown. 
These  have  been  extracted  from  the  complete  document  exam¬ 
ples,  as  shown  in  Figure  4.1,  Appendix  C,  Appendix  B,  Figure 
4.4,  and  Figure  4.2,  respectively. 

The  item  labeled  (a)  in  the  record  formats  for  AUEL  and 
JDS  is  equivalent  to  one  EDI  element,  element  #111.  For 
this  example,  it  is  the  first  element  in  Data  Segment  D1 , 
which  is  part  of  Transaction  Set  #365.  (See  Figure  3.3  for 
the  relationship  between  elements,  segments,  and  sets.  See 
also  Appendix  B. ) 

The  arrows  in  Figure  4.3  indicate  the  conversion  flow 
for  this  item.  Through  the  use  of  the  EDI  tables  (see 
Figure  3.2)  residing  in  the  EDI  conversion  software,  the 
information  in  positions  1-6  of  field  1  in  the  AUEL  detail 
record  is  put  in  EDI  format.  This  element.  Unit 
Identification  Code  (WHGHA A  for  this  example)  ,  which  is 
mandatory,  alpha/numeric,  and  six  characters  (see  Figure  3.5 
for  location  of  this  information)  is  placed  in  the 
appropriate  location  in  the  data  segment.  Upon  receipt,  the 
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13:  AtTEL-Decail  TITLE:  Aim  Cargo  Detail  Record 

DESCRIPTION:  Contain*  Information  to  identify  and  describe  cargo  shipment  units 
applicable  to  unit  saves. 


classtfica 

ticx: 

racLASsmrj 

DENOTE:  103 

POSITION 

FIFLD 

FIELD  TITLES 

RE? 

LCTH 

PJlMAFXS 

1-6 

1 

Dolt  Identification  Code  (UTC) 

A/N 

6 

Control  Field 

7 

2 

Type  Unit  Movement  Data  (77PEDATA) 

A/N 

1 

Control  Pield 

8-13 

3 

Shipment  Coir  Number  (SEIPCNR) 

A/N 

6 

Control  Field 

14 

4 

Load  Number  (LCA2NR) 

1 

a/m 

1 

Control  Field 
Value  is  "t" 
or  numeric 

15-23 

3 

Line  Item  Number  (UN) 

a/h 

6 

21-22 

6 

LIN  Index  Number  (UNIKDCNR) 

N 

2 

23-43 

7 

Item  Description  (nomenclature) 

(HOG  ESC) 

A/N 

21 

44-j3 

8 

Model  Number  (MCDELHR) 

A/N 

12 

56-o3 

9 

Water  Commodity  Code  (VCCMMCD) 

A/N 

5 

• 

61-62 

13 

Type  Panning  (TTPEPACR) 

A 

2 

63-66 

U 

Item  Length  Rounded  ( ITDILOTHP.ND ) 

N 

4 

Rounded  to 
nearest  inch 

67-73 

12 

Item  Width  Rounded  (I7I2dVDTHj2rD) 

N 

4 

Rounded  to 
nearest  inch 

71-74 

13 

Item  Height  Rounded  (ITEbETTHEira) 

N 

4 

Rounded  to 
nearest  Inch 

75-81 

14 

Cross  Weight  Pounds  (CRVTL3S) 

N 

7 

82-aa 

13 

Item  Cubic  Feet  Rounded  (ITEMCVX IKXD) 

N 

7 

a9 

16 

Mode  to  POE  (MCDETDPOE) 

A 

1 

90-92 

17 

Cargo  Citegorty  Code  (CCCCATCDE) 

A/N 

3 

93 

18 

Heavy  Lift  Code  (KVTLFT) 

A/N 

1 

94-133 

23 

Filler 

A/N 

12 

Figure  4.1  Automated  Unit  Eguipment  File  Format 


TRANS-UMD-DATA  (COMPASS  FILE  DATA) 


Ql  TRANS-UMD-DATA. 

02  TRANS-UMD-HDR . 


05 

FILLER 

PIC 

X(S) . 

05 

TRANS-UMD-AREA 

PIC 

99  VALUE 

99  . 

05 

TRANS-UMD- FUNCTION 

PIC 

X  . 

88  TRANS-UMD-ADD 

VALUE  "A". 

88  TRANS-UMD -CHG 

VALUE  "CM . 

88  TRANS-UMD-DEL 

VALUE  "D" . 

05 

TRANS-UMO-OCCURS 

PIC 

99  VALUE 

14. 

05 

TRANS-UMD-LENGTH 

PIC 

9(4)  UALUE  102 

05 

FILLER 

PIC 

X  . 

05 

TRANS-UMD-SUC-CODE 

PIC 

X. 

OS 

T  R ANS-UMO- P  ROUORG 

PIC 

X  . 

05 

TRANS-UMO- ROUTE- LINK 

PIC 

X(6)  . 

05 

TR ANS-UMO- ROUT E-INO 

PIC 

X 

05 

TRANS-UMD-ROUTE-MAP 

PIC 

x  (6 ) 

02 

TRi 

ANS-UMO . 

(a) 

05 

TRANS-UMD-UIC 

PIC 

X(6)  . 

OS 

TRANS-UMO -MOVEMENT-CRP  , 

(c) 

10  TRANS-UMD-CARGO-CAT 

PIC 

X  (  3  )  . 

(d) 

10  TRANS-UMD -HE  AUY-LIFT 

PIC 

X  . 

05 

TRANS-UMD-REC-TYPE 

PIC 

X  . 

OS 

FILLER 

PIC 

X  (  8  )  . 

(b) 

05 

TRANS-UMD-TYPE-DATA 

PIC 

X  . 

05 

TRANS-UMD-REC-CLASS 

PIC 

X  . 

05 

TRANS-UMO-REC- INDICATOR 

PIC 

X  . 

Figure  4.2  Joint  Deployment  System  DMD  File  Format 


05 

TRANS-UMD-REC-CREATED 

PIC 

9(6)  . 

05 

TRANS-UMD-REC-LAST-CHG 

PIC 

9(6)  . 

02 

TRANS-LEUEL-1 . 

05 

TRAN3-UFT  -NBR-C  *  RCO-CATS 

PIC 

9(3)  . 

05 

TRANS-UMD-TOT-STONS-BU 

PIC 

9  ( 6 )  U9  . 

05 

TRANS-UMD-TOT-MTONS-BU 

PIC 

9(7)  . 

05 

TRANS-UMD-TOT-STONS-OUR 

PIC 

9 ( 6 ) U9  . 

05 

TRANS-UMD-TOT-MTONS-OUR 

PIC 

9(7)  . 

05 

TRANS-UMO-TOT-STONS-OUT 

PIC 

9 ( 6 ) U9 . 

05 

TRANS-UMD-TOT-MTONS-OUT 

PIC 

9(7)  . 

05 

TRANS-UMO-TOT-STONS-NAT 

PIC 

9(6)09. 

05 

TRANS- UMD-TCT-MTONS-NAT 

PIC 

9(7)  . 

05 

TRANS-UMD-BULK-POL 

PIC 

9(7)  . 

05 

FILLER 

PIC 

X(2)  . 

02 

TRANS-UMD-LEUEL-2  REDEFINES  TR ANS-UMD-LEUE L- 1 

05 

T  RANS-UMD-C A  RGO-CAT-SUM-SQFT 

PIC 

9(6)  . 

05 

TRANS-UMO-CARGO-CAT-SUM-STONS 

PIC 

9  (  5  )  U9 

05 

T RANS-UMD-C A RGO-C A T-SUM-MTONS 

PIC 

9(6)  . 

05 

FILLER 

PIC 

X  (  50 )  . 

02 

TRANS-UMO-LEUEL-3  REDEFINES  TRAN5-UMD-LEUEL-1 

OS 

FILLER 

PIC 

X(14) 

05 

TRANS-UMO-QUANTITY 

PIC 

9(3)  . 

(j) 

05 

TR ANS-UMO-C A  RGO-DESCR I PT ION 

PIC 

X  (  1  4  )  . 

(e) 

05 

T R ANS-UMO-C A RGO-LENGTH 

PIC 

9(4)  . 

(f) 

05 

T R ANS-UMO-C A  RGO- WIDTH 

PIC 

9(3)  . 

(9) 

05 

TR ANS-UMD-C A  RGO-HE IGHT 

PIC 

9(3)  . 

05 

TRANS-UMD- CARGO- SOFT 

PIC 

9(4)  . 

(h) 

05 

TR ANS-UMO-C A RGO-STONS 

PIC 

9  ( 5 )  U9 

(f) 

05 

TRANS-UMD-CARGO-MTONS 

PIC 

9(6)  . 

05 

FILLER 

PIC 

X  (  2 1 )  . 

Figure  4.2  Joint  Deployment  System  OMD  File  Format  (cont’d) 


AUEL  Record  Format 


POSITION  FIELD 


FIELD  TITLES 


PEP  LGTH 


Unit  Identification  Code  (UIC) 

A/N 

6 

!  Type  Unit  Movenenc  Data  (TYPEDATA) 

A/N 

1 

1  Shipment  Unit  Number  (SHIPUHR.) 

A/N 

6 

Automated  Unit  Equipment  Lijting 


HEAOO'IABTE^S  JNITcJ  STATES  a*my  I 


•  •  •  coMpuTciiiiEo  a o v c ‘a 6 n r  p l a r« n i \ a  an c 


C31PA3S  4630*T  -  JNIT  £ 


TYPE  DATA  9  J  M  I  T  M  A  <-A  £  020?  *P  CO 


sm?ir  c\ 
UNIT  C  \ 


\  SHIPMENT  UNIT 


NU*>£9  h  L\N  I  NO  06  SC. 7  I  PT  ION 


D  I  A6  NS  IONS 
(INCHES) 


w  ■>  ^  CO  T*  01  TPAILEP  CABGO  1  /4  TON  *416 


EET  Data  Set  format 


1111  1 D 1 02  146 

;  !  !  Typ? 

,  UMD 

06/06 1  I  n  AN  01/01 


D 1 03  93' 

I 

Name  | 
I 

0  AN  01/35 | 


EDI  Transmission  Format 


-0209  MP  C0-FT  MEADE-MD-US 
400—0 1-M416-875Z9-VE-U-3 


JDS  UMD  Record  Format 


05  TRflNfs-VMD-ROVTE-MPP 

02  TRflNS-M^O. 

- 

PIC 

x  ( 6  ) 

05  T  RflNS- VMD-U I C 

PIC 

X(6) 

OS  TRflNS-UMD -MOVEMENT -GRP 


Figure  4.3  Conversion  Flow  of  a  Single  Data  Item 


EDI  software  at  the  receiving  site  transforms  this  element 
(again,  through  the  use  of  the  tables)  into  JDS  format,  as 
determined  by  JDS  record  format  reguirements.  It  is  then 
available  for  inclusion  in  JDS  reports  or  for  visual  recall 
as  part  cf  any  one  of  a  number  cf  information  screens  on  the 
system  terminals  at  JDA. 

This  same  conversion  flow  occurs  for  each  piece  of 
information  which  must  be  transmitted.  It  is  especially 
important  to  note  the  number  and  size  of  those  data  items 
found  in  the  AUEL  file  but  not  used  in  the  UMD  file.  Under 
the  current  system  this  information  is  automatically  trans¬ 
ferred  to  JDA  and  stripped  from  the  file  after  receipt  of 
the  entire  file.  Using  the  EDI  method,  only  those  data 
elements  actually  used  are  transferred.  This  can  be  seen  in 
Figure  4.4,  which  shows  the  data  after  it  has  been  converted 
into  EDI  standard  data  elements  and  data  segments  for  trans¬ 
mission.  All  other  fields  can  be  transferred  using  one  or 
more  of  the  optional  data  segments,  but  only  when  deemed 
appropriate  by  the  sender. 

Appendix  C  contains  examples  of  the  types  of  data  main¬ 
tained  in  COMPASS  and  transferred  to  JDS.  The  data  in  these 
listings  is  currently  transferred  in  the  record  format  shown 
in  Figure  4.1  Examination  of  these  listings  shows  the 
considerable  duplication  of  data  being  transmitted.  The 
same  essential  information,  in  a  considerably  more  compact 
form,  is  transmitted  using  EDI  Transaction  Set  365,  Unit 
Movement  Data  (Appendix  B)  .  This  transaction  set,  while 
demonstrating  the  basic  format  of  transaction  sets,  also 
lists  the  associated  data  segments  which  would  be  reguired 
for  this  specific  application.  Appendix  A  is  a  section  of  a 
Data  Element  Dictionary,  which  includes  a  partial  list  of 
the  data  elements  used  in  these  data  segments.  Comparison 
between  present  formats  and  the  EDI  transmission  set  (Figure 
4.4  shows  that  considerable  reduction  in  transmitted  infor¬ 
mation  can  be  realized  using  EDI. 
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TRANSACTION  SET  -  <>255  UNIT  MOVEMENT  DATA 


(EG  SEGMENT) 

(G3  SEGMENT) 

ST-265-TRANSC001 

3GF-FI-F12G3 

N1  -f U-USARMY  FORSCCM-fl1 -COMPASS 
N2-US  army  forces  ccmmano  heaoquarters 
NTiC'JQINT  ceplqyment  agency -g-jds/umo 

OI-GHISKL-O-GOSI  AO  EM  91  3TY  A  VULC-FT  CRD-CA-US 

02-X60833— 02-M1S1A2-97SZ9-V0-U-7 

03* TRUCK  UTILITY  1/4  T0M-132*54*S3*M*24S0-L*2£5*€ 

Q4-0VR-9 

02-1195400— Q1-M416-97SZS-VE-U-7 

03-TRAILER  CARGO  1/4  TGN-132-54-S3-N-24S0-L-2S5-E 

04-OVR-A 

02-X39940— 02“MS  1 6 1  WWN-97SZ9-V0-U-2 

03-TRUCK  CARGO  1-1/4  TON-231 »35-72*N-7480“L-920“S 

04-QVR-K 

G2*  J96845— 92-*i167-97529-vE-*J-1 

03-GUN  AA  TOUEO  2CMn-lS3-78-56-N-3250-L-467*E 

Q4-GVR-9 

0 1  —aHGHA A-R-02C9  TIP  CC-FT  MEAOE-TlOTJS 
02-J9S4Q0—  01-M416-97529-VE-J-3 
03-TRAILER  CARGO  1/4  TCN-1G9-62-44-N-S30-L-170-E 
04-OVR-A 

02-V95400CA)— 01— MX-U-3 

03-L0A0-(1ISC  TOE  GRG  ECUIP— S0Q-L-2C-E 

02*X40009~  02-Tl2SA2’375Z9'V0-J-l 

03-TRUCK  CARGO  2-1/2  T0N-265-95-38-M-131801.-12S2- 

04-0UR-S 

02-X40009CA)— 02— MX-U-1 

03-L0AO-MISC  TCE  ORG  EQUIP - 4820-L-270-S 

02-X40146— 02-M3SA2  ttil«N-375Z9*VO-U-l 

03-TRUCK  CARGO  2-1/2  TON-279*95-e3*N-13570-L-l2SS*t 

04-OVR-S 

02”X40146(A)— 02— T1X-U-1 

03-LCAQ-nlSC  TOE  ORG  EQUIP— 4820-L-270-E 

02-"J9S3 1 1  — 02-ni  0SA2-37SZ9-JE-U-2 

03-TRAILE.R  CARGO  1-1/2  T-166-93*92“N«2570*L*554-E 

04-OVR-9 

02-J9S311(A)—  02— MX-U-2 

03 “LOAD -M ISC  TOE  GRG  EQUIP— 2920-L *200*5 


K4 -COMMENTS 
SE-23-TRANS0001 


(Gc  SEGMENT) 
(EG  SEGMENT) 


Figure  4.4  Transmission  of  Data  Set  #365  in  EDI  Format 


E.  EDI  ADVANTAGES 


The  data  elements,  segments,  and  sets  utilized  in  the 
EDI  concept  are  designed  to  be  applicable  to  a  wide  variety 
of  applications.  Through  the  use  of  the  table-driven 
system,  command  unique  forms  can  be  translated  into  generic 
data  elements,  and  combined  into  transaction  sets  which  can 
be  transmitted  to  many  other  organizations.  Because  the 
receiving  organizations'  EDI  software  will  translate  the 
transmitted  elements  into  locally  desired  formats,  the  same 
transmission  could  actually  result  in  reports  in  vastly 
different  formats  at  multiple  locations.  This  highlights 
one  of  the  major  benefits  of  the  EDI  procedures:  standard 
formats  are  not  required  for  effective  community-wide  data 
transfers. 

As  shown  above,  the  problems  arising  under  the  current 
data  transfer  procedures  are  primarily  the  result  of  ineffi¬ 
cient  use  of  existing  communica tions  assets.  As  previously 
discussed  the  current  system  reguires  transfer  of  the  entire 
COMPASS  file,  including  data  elements  not  required  for  use 
in  JDS.  This  file  is  then  interpreted  at  JDA,  the  necessary 
data  is  extracted  from  the  COMPASS  file  and  inserted  in  the 
proper  format  into  the  HMD  file  in  the  JDS  data  base.  The 
actual  file  transfer  is  accomplished  as  a  tape-to-tape 
transfer  using  the  File  Transfer  Service  (FTS)  of  the  PIN. 

The  basic  nature  of  a  tape-to-tape  transfer  automati¬ 
cally  makes  this  a  relatively  slow,  inefficient  process.  In 
a  rather  volatile  network,  subject  to  frequent,  if  minor, 
interruptions  in  communications  service,  this  often  necessi¬ 
tates  numerous  retransfers  of  previously  delivered  data  in 
an  effort  to  ensure  accuracy  of  the  total  file.  In  this 
demonstration,  we  propose  a  disk-to-disk  transfer  in  order 
to  eliminate  the  need  to  retransmit  the  entire  file  if  the 
transfer  is  interrupted  by  a  communications  break.  This 


alone  will  significantly  reduce  the  time  lag  between  the 
locations  involved,  and  thus  increase  the  probability  that 
the  data  will  agree  at  both  sites. 

An  even  more  effective  difference  between  the  current 
transfer  method  and  the  EDI  method  demonstrated  here  is  in 
the  vastly  reduced  amount  of  data  reguired  to  be  sent.  The 
EDI  method,  as  shown  in  Figure  4.4,  requires  that  only  those 
data  elements  actually  used  at  the  receiving  site  be  trans¬ 
ferred.  The  determination  of  reguired  elements  is  made 
through  the  table-driven  operations.  Data  elements  not 
reguired  are  listed  as  optional  in  the  data  segments.  In 
fact,  in  some  cases  the  data  segments  are  optional, 
depending  upon  to  which  site  (s)  the  transaction  set  is 
transferred.  By  eliminating  unnecessary  data  from  the 
transaction  set,  the  sender  can  ensure  the  most  efficient 
use  of  the  computer  systems  and  the  communications  network. 
In  this  example,  a  reduction  of  approximately  50%  in  trans¬ 
mitted  data  would  be  realized. 


F.  SUMMARY 


Within  the  joint  deployment  community,  extensive  data 
transfers  are  necessary  for  planning  and  execution  of 
deployment  efforts.  In  a  scenario  involving  MTMCWA,  7th 
Infantry  Division,  FORSCOM,  and  JDA,  data  transfers  such  as 
the  one  demonstrated  would  be  reguired.  The  current  trans¬ 
fers  utilize  tape-to-tape  transfers  and  transmit  entire 
reports,  including  redundant  information,  and  information 
utilized  at  the  originating  end  but  not  the  receiving  end. 
Data  transfers  to  satisfy  the  same  scenario  reguirements. 


but  utilizing  the  EDI  method,  provide  several  benefits. 
Conversion  to  multiple  formats  for  multiple  receivers  is  not 
necessary.  Disk-to-disk  transfers  reduce  the  necessity  for 
retransmission  in  case  of  interrupted  transmission. 


case  of 


V.  INTERFACE  AIPLICATIONS 


A.  INTRODUCTION 

The  previous  chapters  have  established  the  necessity  for 
an  efficient  electronic  data  interchange,  and  have  demon¬ 
strated  the  technical  feasibility  of  the  EDI  concept  as  just 
such  an  exchange. 


Deployment  management  systems  (personnel,  hardware, 
communications  equipment,  software,  procedures)  must 
collectively  support  the  deployment  process  from  the 
National  Command  Authorities  (NCA)  level  to  the  instal¬ 
lation  level  using  fully  integrated  concepts  which 
maximize  our  deployment  capabilities  and  provide  neces¬ 
sary  surge  capacity  to  meet  time-sensitive  crisis  and 
wartime  requirements.  [Ref.  11:  p.  14] 


Joint  planning  experiences  and  exercises  have  shown  the  need 
for  better  coordination  and  understanding  of  the  myriad 
mobilization  and  deployment  information  systems  which  either 
currently  exist  or  have  been  conceptually  determined. 
[Ref.  2]  A  brief  discussion  of  some  of  these  systems  should 
highlight  potential  applications  of  an  interchange  such  as 
the  EDI  concept. 


B.  INTEGRATED  NETWORKS 
1 .  TC  ACCIS 

One  significant  advancement  toward  the  implementa¬ 
tion  of  an  automated  interface  is  the  development  of  the 
Transportation  Coordinator  Automated  Command  and  Control 
Information  System  (TC  ACCIS)  prototype.  TC  ACCIS  is  a 
response  to  lessons  learned  during  JDA  directed  exercises 
regarding  our  ability  to  deploy  forces  and  sustain  materiel 
and  personnel  under  crisis  conditions.  The  JDA  is  the  Joint 


Project  Manager  of  this  development  effort  which  is  being 
conducted  within  the  WHMCCS  Research  and  Development 
program.  The  TC  ACCIS  effort  will  provide  an  automated  unit 
movements  data  base  at  the  unit  and  shipper  level,  an  auto¬ 
mated  surge  capability  to  the  installation  transportation 
coordinator,  and  an  automated  interface  between  the 
Installation  Transportation  Office  (ITO)  and  the  associated 
TOA. 

2 .  TC  PIS 

A  planned  enhancement  to  the  TC  ACCIS  prototype, 
called  the  Transportation  Coordinator  and  Deployment 
Information  System  (TC  DIS)  ,  includes  an  interface  with 
major  commands  in  an  effort  to  give  them  improved  visibility 
over  the  deployment  status  of  units  assigned  to  them  and 
provides  them  a  capability  to  influence  the  situation.  In 
addition,  TC  DIS  provides  an  interface  directly  from  the 
unit,  where  it  is  generally  agreed  the  most  current  informa¬ 
tion  is  of  necessity  available,  to  the  JDS. 

The  TC  DIS  concept  recognizes  multicommand,  multi¬ 
functional  interfaces  during  the  deployment  management 
process.  Service  and  command  systems  which  already  exist 
can  be  complemented  by  automation  through  electronic  inter¬ 
faces.  Existing  systems  are  generally  stand-alone  func¬ 
tional  systems.  Some  use  notional  data  as  their  basis  for 
initial  planning.  Aging  can  occur  because  data  maintainers 
do  not  always  have  ready  access  to  the  systems  for  updating. 
[Ref.  11:  p.  32] 

C.  SERVICE  SYSTEMS 

Service  systems  which  were  created  at  the  MAJCOM  level 
include  DEMSTAT,  COMPASS,  and  COKPES.  Existing  systems  at 
the  TOA  level  which  provide  networks  for  reporting  vital 


movement  information  from  support  elements  at  installations 
and  POE s  to  the  TOAs  include  SSM5,  SPUR ,  ASPUR,  TOLS,  WEIS, 
and  KAIRS.  Many  of  the  systems  which  exist  at  the  MAJCOM 
level  are  also  located  at  the  installation  level.  These 
systems  usually  have  existing  interfaces  within  the  overall 
system  between  levels,  and  could  potentially  be  connected 
under  the  TC  DIS  concept.  Additionally,  there  are  systems 
still  in  development  phases  which  will  provide  enhancements 
to  the  automation  of  the  deployment  community  information 
requirements. 

1 .  MA JCOM  L evel  Systems 
a.  DEMSTAT/CCMPASS 

The  Deployment,  Employment,  Mobilization  Status 
System  (DEMSTAT)  was  developed  to  provide  Forces  Command 
(FORSCOM)  with  a  system  which  would  place  in  execution  those 
plans  developed  in  planning  systems  such  as  JDPS.  It  is 
activated  during  crisis  situations,  and  combines  several 
automated  planning  systems  utilizing  ADP  resources  of 
fiWMCCS.  This  system  is  used  to  identify  units  for  specific 
operations  and  to  manage  those  forces  during  the  execution 
of  the  operation.  When  activated,  the  DEMSTAT  database  is 
the  "sole  source  for  execution  of  all  mobilization/ 
deployment/employment  operations  and  the  operation’s  associ¬ 
ated  requirements."  [Bef.  2:  p.  34 J  The  dataoase  is  updated 
by  automated  reports  from  FOESCCM  itself,  from  J  DA,  and  from 
reporting  commands/installations.  [Ref.  2:  p.  35] 

The  DEMSTAT  system  is  the  execution  system  which 
is  used  in  conjunction  with  the  planning  system  COMPASS. 
The  primary  objective  of  COMPASS  is  to  provide  an  automated 
system  with  unit  movement  information  used  in  mobilization 
and  deployment  planning.  Information  in  COMPASS  is  used  to 
create  the  AUEL  which  provides  the  unit  movement 


requirements  information  to  MTMC.  These  two  systems  have  no 
real  automated  interface,  although  the  information  in 
COMPASS  is  used  in  DEMSTAT.  There  is  presently  an  interface 
between  DEMSTAT  and  JDS,  where  information  is  transferred 
through  an  existing  automated  interchange  via  AUTODIN, 
although  the  WIN  is  not  used.  DEMSTAT  uses  fewer  fields 
than  JDS,  and  so  when  the  transfers  occur,  the  fields  appro¬ 
priate  to  DEMSTAT  are  stripped  from  the  information  trans¬ 
ferred  by  JDS.  This  interface  is  representative  of  the 
command  to  command  interface  as  discussed  in  Chapter  II. 

b.  COMPES 

The  Contingency  Operation/Mobility  Planning  and 
Execution  System  (COMPES)  ,  an  Air  Force  standard  system,  is 
comprised  of  three  modules:  an  Operation  Plan  Module,  a 
logistics  Module,  and  a  Manpower/Personnel  Module.  This 
system  is  implemented  at  both  the  MAJCOM  and  base  levels 
throughout  the  Air  Force.  Its  functions  include  logistics 
planning  applications  and  monitoring  the  status  of  deployed 
units.  The  Logistics  Module  in  particular  was  designed  to 
satisfy  the  needs  of  both  base-level  and  MAJCOM  logistics 
planners  responsible  for  deployment  planning.  COMPES' 
primary  benefit  is  to  provide  "...a  standard  Air  Force 
deployment  planning  system  which  will  minimize  training 
requirements,  and  provide  a  standard  reference  system  for 
interccmmand  deployment  planning. "  [Ref.  2:  p.  23]  There 
are  existing  interfaces  between  COMPES  at  the  MAJCOM  level 
and  the  base  level.  There  are  also  interfaces  between 
COMPES  and  JOPS  and  UNITREP.  Those  interfaces  currently 
involve  data  transfer  via  AUTODIN  using  tape  to  tape  dump. 


Vv 


2.  Installation /TO A  Level  Systems 


a.  SEMS 

The  Marine  Corps'  Standard  Embarkation 
Management  System  (SEM5)  provides  deployment  planning  docu¬ 
mentation  and  execution  planning  assistance  for  amphibious 
operations  worldwide.  The  information  in  SEMS  includes  unit 
personnel,  supply,  and  equipment  information  at  the  squadron 
and  battalion  level.  Standalone  deployable  minicomputers 
are  used,  with  diskettes  which  can  be  processed  on  the  Fleet 
Marine  Force  (ADPE-FMF)  IBM  4  110  computer.  There  are  no 
current  interfaces  with  other  deployment  systems.  However, 
the  SEMS  is  precisely  the  type  cf  system  which  would  benefit 
from  an  EDI  interchange  as  postulated  in  the  TC  DIS  concept. 
[Ref.  2:  p.  74] 

b.  SPUR/ASP  DR 

The  System  for  Predetermining  Unit  Requirements 
(SPUR)  is  "an  initial  step  towards  documentation  simplifica¬ 
tion  aimed  specifically  at  unit  deployments  to  overseas 
locations  under  emergency  conditions."  [Ref.  2:  p.  77]. 

SPUR  obtains  much  of  its  data  from  the  AUEL  generated  by 
COMPASS.  The  information  is  stored  either  in  magnetic  tape 
files  or  disk  packs.  Objectives  of  SPUR  include: 

Eliminate  ITO  of  detailed  Routing  Requests  at  deployment 

Eliminate  unit  submission  of  Advanced  Transportation 
Control  Movement  Document  (ATCMDs)  at  deployment  time 

Reduce  the  MILSTAMP  document  work  load  at  embarkation 
terminals  by  preplacement  of  ATCMDs  in  the  TERMS  data 
base. 

Provide  area  commands  with  an  automated  data  base  of 
unit  leading  information  collected  in  advance.  [Ref.  2: 

P.  77] 
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There  are  no  current  interfaces  witn  other 


systems.  However,  SPUE  is  the  foundation  for  an  automated 
system  which  is  scheduled  to  become  operational  in  Kay  1985. 
This  system  (Automated  Systems  for  Processing  Unit 
Requirements  -  ASPUE)  will  ccrtinue  to  provide  the  capa¬ 
bility  to  receive  and  process  requirements  from  the  A UEL. 
One  of  its  proposed  primary  functions  is  to  receive, 
process,  and  store  movement  requirements  from  TC  ACCIS  as 
well  as  other  sources  such  as  METS,  TOLS,  and  JDS.  These 
data  transfers  will  be  accomplished  by  using  a  high  speed 
central  processor.  [Bef.  2:  pp.  11-12] 


c.  MAIRS 


The  Military  Air  Integrated  Reporting  System 
(MAIRS)  provides  automated  support  for  the  Military  Airlift 
Command  (MAC)  .  It  provides  information  such  as  aircraft 
movement  and  delays,  passenger  and  cargo  requirement 
summaries,  and  movement  data  to  MAC,  MAC  Numbered  Air 
Forces,  and  the  JCS.  There  is  currently  an  interface  with 
AIMS,  another  Air  Force  automated  system.  There  are  no 
interfaces  with  other  TOA  or  deployment  related  systems, 
although  the  potential  exists  fcr  interface  with  the  JDS.  A 
test  M AIR S— JDS  interface  has  been  proposed,  which  will 
forward  airlift  arrival/departure  information  to  JDS.  This 
interface  will  utilize  AUTODIN.  [Ref.  2:  pp.  53-54] 


D.  SUMMARY 


Systems  which  represent  significant  advancement  in  the 


automated  interface  arena  are  the  TC  ACCIS  and  the  TC  DIS. 


The  TC  DIS  is  an  enhancement  to  the  TC  ACCIS,  and  will 
provide  a  direct  interface  between  the  unit  and  JDS.  There 
are  a  variety  of  automated  systems  throughout  the  joint 
deployment  community,  with  a  wide  range  of  existing 


interface  capabilities.  The  potential  exists  within  most  of 
these  systems  for  increased  interfaces,  as  indicated  in 
Figure  2.3.  The  EDI  method  of  interfacing  is  ideal  for  many 
of  these  applications.  Since  each  of  the  systems  described 
above  was  designed  and  developed  by  individuals  for  the 
separate  services,  some  of  the  data  descriptions  and  formats 
may  differ  according  to  the  given  service  reguirements.  The 
EDI  concept  is  designed  precisely  to  address  these  types  of 
issues;  therefore,  this  interchange  concept  would  be  appro¬ 
priate  for  interfacing  systems  throughout  the  community. 


VI.  IMPLEMENTATION  COH5IDEEATION5/BBCOMMENDATIONS 


A.  INTEODDCTION 


In  order  to  effectively  implement  any  interface  system, 
the  coordination  and  cooperation  of  all  involved  services  or 
agencies  is  essential.  For  the  purpose  of  this  discussion 
those  involved  agencies,  termed  the  Joint  Deployment 
Community  (JDC)  ,  are  collectively  referred  to  as 


Those  headquarters,  command,  and  agencies  involved  in 
the  training,  preparation,  movement,  reception,  employ¬ 
ment,  support,  and  sustainment  of  military  forces 
assigned  or  committed  to  a  theater  of  operations  or 
objective  area.  The  JDC  usually  consists  of  the  OJCS, 
Services,  certain  service  major  commands  (including  the 
Service  wholesale  logistic  commands)  ,  unified  and  speci¬ 
fied  commands  {and  their  service  component  commands)  , 
DLA ,  the  TOAs,  JDA,  joint  task  forces  (as  applicable), 
and  other  defense  agencies  (e.g.,  DIA)  as  may  be  appro¬ 
priate  to  a  given  scenario.  [fief.  5:  p.  x] 


It  is  immediately  apparent  that  when  such  a  large  group  of 
diverse  organizations  must  agree  on  any  concept  of  opera¬ 
tions,  problems  are  bound  to  arise.  Therein  lies  a  major 
obstacle  to  the  acceptance  cf  this  proposed  interface 
system. 


B.  JOINT  DEPLOYMENT  COMMUNITY  EEACTIONS 

There  is  almost  unanimous  agreement  throughout  the  JDC 
that  the  need  exists  for  an  automated  interface  between  the 
units,  the  TOAs,  and  JDA.  Additionally,  virtually  all  agree 
that  state  of  the  art  technology  is  readily  available  to 
accomplish  the  necessary  hardware  and  software  connectivity. 
However,  there  is  widespread  disagreement  among  the  various 
participants  regarding  the  required  level  of  interface,  the 
necessary  detail  of  data  exchange,  and  which  particular 
technical  solution  to  implement. 


Analysis  of  the  JDC  responses  to  the  proposed  TC  ACCIS 
and  TC  DIS  reveals  a  wide  disparity  of  opinions  about  the 
feasibility  of  both  TC  ACCIS  and  the  expanded  capabilities 
of  TC  DIS.  Although  many  representatives  throughout  the 
community  favor  the  overall  concept  of  TC  ACCIS,  there  are 
just  as  many  who  disagree  with  large  portions  of  the  plan. 
Even  among  its  supporters,  there  are  overriding  concerns 
about  the  ability  of  the  community  as  a  whole  to  make  the 
system  work.  Some  cf  the  more  frequently  raised  objections 
are  described  below. 

1 •  ITO/JDS  Interface  Necessity 

A  primary  concern  is  whether  or  not  there  is  truly  a 
need  for  direct  interface  between  the  automated  unit  data 
base  and  the  JDS.  Such  an  interface  is  proposed  in  the  TC 
DIS  ECC  as  a  one-way  link  with  the  JDS  having  access  to  unit 
data  but  the  unit  having  no  need  for  access  to  the  JDS  data 
base.  This  is  obviously  for  security  purposes,  to  protect 
the  classified  data  maintained  within  JDS.  There  are  a 
number  of  objections  to  this  interface: 

•  One  of  the  basic  premises  in  the  TC  DIS  ROC  is  that  the 

transfer  of  unclassified  unit  information  from  the 
installation  data  base  would  be  in  an  unclassified 
mode.  The  assumption  that  all  unit  data  is  unclassi¬ 
fied  is  not  necessarily  valid.  Certain  information 

about  individual  units  when  combined  within  a  partic¬ 
ular  installation’s  data  base  becomes  more  sensitive. 

•  In  a  crisis  situation,  the  supported  CINCs  obtain 

necessary  information  about  the  current  deployment 
status  of  required  forces  and  material  through  the  JDS. 
Much  of  this  information  is  already  available  to  JDS  in 
other  existing  systems.  The  remainder  of  the  required 
information  could  be  obtained  by  JDS  from  the  TOA. 
This  is  especially  true  if  the  proposed 

installation/TO A  interface  can  be  developed. 


•  There  is  significant  disagreement  concerning  the  level 
of  detailed  data  actually  required  within  the  JDS.  The 
services  tend  to  believe  that  allowing  the  JDS  a  direct 
interface  with  the  units  would  increase  a  perceived 
tendency  on  the  part  of  JDA  to  micro-manage  every 
aspect  of  deployment. 

•  There  is  a  major  'turf  battle*  ensuing  between  the 
services  and  the  JDA.  The  services  feel  that  the  JDA 
has  more  than  overstepped  its  bounds  by  even  indicating 
that  subordinate  organizations  should  report  directly 
to  them  without  following  through  normal  command  chan¬ 
nels.  None  of  the  services  are  willing  to  give  up 
control  of  their  own  forces  to  this  extent. 

2  •  System  Compatibility 

Concern  has  also  been  expressed  that  any  new  system 
development  must  be  made  compatible  with  existing  service 
unique  systems.  There  is  a  feeling  among  the  community  that 
some  aspects  of  TC  ACCIS  are  not  adeguately  considering  this 
compatibility.  Additionally,  the  Joint  Reporting  Structure 
(JRS )  requirements  must  be  carefully  considered  to  enhance 
unit  reporting  and  to  modernize  the  JRS.  A  primary  thought 
here  is  that  TC  ACCIS  implementation  should  be  carefully 
monitored  to  ensure  that  nc  additional  reporting  is 
required. 

3-  Communications  Capacity 

Any  new  interfaces,  regardless  of  the  level,  would 
be  heavily  dependent  on  the  fiKMCCS  Intercomputer  Network 
(FIN)  for  the  communications  transfer  of  the  actual  data. 
The  WIN  is  already  severely  taxed  to  satisfy  current 
operational  requirements.  Some  of  the  members  of  the  commu¬ 
nity  feel  that  added  interface  requirements  might  over 
encumber  existing  WW MCCS  facilities. 


As  already  alluded  to,  there  is  the  significant 
problem  of  data  classif ication  and  the  security  of  classi¬ 
fied  information.  It  is  inevitable  that  even  unclassified 
data  at  unit  level  will  ultimately  be  classified  at  some 
higher  level  as  it  is  incorporated  into  the  JDS.  The  JDS 
data  base  is  TO?  SECRET.  There  are  many  questions  regarding 
the  ability  to  adequately  protect  potentially  classified 
data  in  an  interface  between  remotely  located  computer 
syst  ems . 

5 .  Modernization  Efforts 

Finally,  all  participants  in  the  JDC  have  expressed 
interest  in  the  evolution  of  both  the  JOPES  and  the  PIS.  It 
is  imperative  that  these  proposed  interfaces  be  developed  in 
conjunction  with  the  WtfMCCS  standard  JOPES  and  PIS  efforts. 


C.  EDI  IMPLEMENTATION  LIMITATIONS  AND  DIS ADVANTAGES 

Some  of  the  above  issues  suggest  limitations  or  disad¬ 
vantages  to  implementation  of  the  EDI  concept.  Some  of 
these  are  actually  ’political*  problems  as  opposed  to  tech¬ 
nical  problems,  and  as  such  are  beyond  the  scope  of  this 
thesis. 

Security  issues  are  a  combination  of  political  and  tech¬ 
nical  problems.  The  EDI  interface  software,  consisting  of 
the  data  elements,  segments  and  sets  and  the  associated 
tables,  do  not  inherently  possess  security  restrictions.  It 
is  assumed  that  the  security  issues  will  be  handled  by  the 
command's  existing  computer  hardware  and  software. 
Determination  of  access  require nents/allowances  must  be  made 
prior  to  concept  implementation;  the  potential  exists  for 
concept  limitations  based  on  security  requirements. 
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The  disadvantages  associated  with  implementation  of  an 
interface  utilizing  the  EDI  concept  are  primarily  initial 
disadvantages.  The  most  significant  effort  required  would 
be  the  programming  needed.  Each  command  utilizing  the 
concept  will  need  a  program  which  provides  the  interface 
ietween  their  current  system  and  the  EDI  software.  While 
this  effort  is  substantial,  it  is  for  the  most  part  a  one¬ 
time  operation.  Once  the  program  is  running,  modifications 
to  incorporate  command  changes  are  minor. 

Associated  with  this  interface  software  is  also  the 
computer  time  and  space  required  for  its  operation.  While 
this  differs  from  system  to  system  and  is  thus  hard  to  quan¬ 
tify  in  a  general  sense,  it  dees  reduce  computer  capacity 
available  for  intra-command  operations. 

Another  'cost'  incurred  when  implementing  the  EDI 
concept  is  the  community  wide  requirement  to  identify  data 
sets,  segments,  and  elements  necessary  for  the  interface. 
The  majority  of  these  items  are  in  existence,  as  those 
developed  by  TDCC  are  designed  to  be  applicable  to  a  variety 
of  industries.  In  some  cases,  additional  codes  may  be 
required  to  enable  the  use  of  existing  data  elements.  There 
would  probably  be  more  new  sets  and  segments  required  for 
application  to  the  joint  deployment  community.  It  will 
require  high  level  support  of  the  EDI  concept  to  ensure 
timely  agreement  among  the  users  on  the  exact  makeup  of  the 
new  sets  and  segments.  In  order  to  assist  in  both  the 
creation  of  these  items  and  the  software  design  described 
above,  TDCC  offers  two-day  sessions  intended  to  provide 
selected  individuals  the  necessary  training  and  information. 

Although  this  training  is  available,  the  assistance  of  a 
civilian  company  in  the  software  design  will  likely  be 
required.  There  are  several  companies,  primarily  in  the 
Washington  D.C.  area,  which  can  provide  this  service.  Their 
names  may  be  obtained  from  the  TDCC.  The  cost  for  such 


assistance  would  be  completely  dependent  upon  the  extent  of 
assistance  required. 

One  potential  political  obstacle  to  the  implementation 
of  the  EDI  concept  is  the  community-wide  acceptance  of  this 
concept  as  the  appropriate  alternative.  The  high  level 
support  and  commitment  required  does  not  presently  exist. 
However,  the  need  for  improvement  in  the  community  today  has 
become  more  apparent,  and  support  for  community-wide  inter¬ 
face  is  growing,  as  evidenced  by  the  money  and  effort 
invested  in  the  TC  ACCIS  and  TC  DIS  programs. 

D.  BENEFITS  OF  EDI 

We  fully  accept  that  all  of  these  concerns  are  valid  and 
we  realize  that  many  of  the  issues  must  be  resolved  before 
any  effort  is  made  toward  implementing  the  system  interfaces 
proposed  by  TC  ACCIS  and  by  this  thesis.  Some  of  the  ques¬ 
tions  raised  are  more  within  the  political  realm  and  must  be 
solved  by  careful  coordination  with  the  agencies  or  organi¬ 
zations  involved.  Those  types  of  issues  are  not  being 
addressed  here. 

However,  many  of  the  supposed  ’problems'  would  net  be 
problems  at  all  if  the  EDI  standard  interface  system,  as 
demonstrated  in  this  thesis,  was  adopted  as  the  technical 
solution  to  the  actual  data  exchange  portion  of  the  TC  ACCIS 
and  TC  DIS. 

One  of  the  major  issues  is  the  current  requirement  that 
existing  service  unique  systems  would  have  to  be  converted 
to  be  compatible  with  the  JDS  data  element  structure  in 
order  to  effectively  accomplish  any  interface.  Using  the 
proposed  EDI  system,  there  would  be  no  need  for  the 
interface  data  bases  to  be  maintained  in  identical  format. 
All  existing  and  potential  systems  could  be  designed 
according  to  individual  service  requirements.  The  EDI 
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interface  programs  automatically  perform  the  conversions 
necessary  to  allow  each  system  to  interface  with  the  stan¬ 
dard  data  elements.  This  provides  automatic  interfacing 
between  each  system  and  JDS.  An  added  benefit  of  the  EDI 
conversion  technique  is  that  any  system  can  also  interface 
with  any  other  system  using  the  same  conversion  program. 
Thus  it  is  easily  possible  for  the  three  TOAs  to  have  inter¬ 
faces  with  each  other  as  well  as  the  proposed  interface 
between  the  TOAs  and  JDS. 

There  would  be  seme  effort  required  initially  to  develop 
standard  data  sets  for  transfers  unique  to  military  require¬ 
ments.  However,  the  advantages  of  using  EDI  far  outweigh 
the  time  and  manpower  required  to  establish  these  standard 
data  sets.  First,  once  the  standard  data  sets  are  deter¬ 
mined,  new  systems  can  be  added  and  easily  interfaced  with 
the  addition  of  only  one  new  conversion  program. 

Second,  the  process  of  converting  data  files  into  the 
standard  data  sets  automatically  eliminates  all  but  the 
essential  information  which  must  be  transmitted.  This  would 
significantly  reduce  the  amount  of  extraneous  data  being 
sent  over  already  overloaded  communications  systems.  In 
fact,  use  of  the  standard  data  sets  should  minimize  use  of 
the  WIN,  thus  allowing  it  to  be  available  for  more  interac¬ 
tive  applications. 

Finally,  and  most  notably,  the  adoption  of  the  EDI 
interface  by  the  JDC  would  improve  the  overall  effectiveness 
of  the  joint  deployment  process.  Providing  an  automated 
interface  enabling  direct  connection  between  all  the  partic¬ 
ipating  agencies  would  ensure  that  the  individual  data  bases 
at  each  agency  are  as  much  as  possible  in  agreement  with 
other  agencies  involved.  Thus  when  an  actual  deployment 
must  take  place,  all  concerned  parties  will  have  ready 
access  to  current  data  which  they  require  to  accomplish 


E.  SUMMARY 


The  necessity  for  continuous  interaction  between  members 
of  the  joint  deployment  community  is  obvious.  Current 
systems  and  interfaces  are  not  providing  the  efficient  and 
accurate  data  transfers  required.  Standardization  is  the 
solution  most  commonly  proposed  to  alleviate  the  current 
situation.  This  proposal,  however,  has  drawbacks  which  have 
been  previously  discussed. 

The  EDI  concept  -  a  table-driven  electronic  interface 
utilizing  data  elements,  segments,  and  sets  -  is  a  proposed 
interface  which  would  provide  the  necessary  data  transfer 
capabilities  throughout  the  community.  While  there  are  many 
concerns  about  implementing  this  system,  most  of  them  are  in 
the  political  realm,  and  are  beyond  the  scope  of  this 
thesis.  The  technical  feasibility  of  the  EDI  concept  has 
been  proven  in  use  in  several  industries  over  the  past  few 
years.  The  application  of  this  system  to  the  military  has 
been  demonstrated  in  this  thesis.  Implementation  within  the 
joint  deployment  community  wculd  alleviate  many  of  the 
current  inadequacies  and  provide  an  advanced,  efficient 
means  of  data  transfer  which  would  contribute  to  the  profes¬ 
sional  performance  of  the  joint  deployment  community. 
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APPENDIX  A 

DATA  ELEMENT  DICTIONARY 


This  appendix  is  a  partial  EDI  Data  Element  Dictionary. 
The  elements  included  here  are  used  in  the  transaction  set 
shown  in  Appendix  B.  These  elements  correspond  to  the  data 
fields  in  a  user  site's  data  base. 


15  CITY  NAME 


(Spec: 

Type  =  AN  Min  =  2; 

Max  = 

19) 

Free-f orm 

text  for  city  name 

Reference 

Designator (s) :  D40 1 

D701 

D906 

E40  1 

E701 

F  40  1 

F70  1 

F906 

G40  1 

H502 

L715 

N40  1 

NAM0  5 

R 1 2  0  3 

RT20  5 

R  IN  04 

S  402 

S903 

T205 

T  2 1  0 

T604 

T607 

2T0  3 

U401 

U90 1 

V905 

H3  0  4 

W404 

Y  10  6 

22  COMMODITY  CODE 

{Spec:  Type  =  AN  Min  =  1;  Max  =  10) 

Alpha/numeric  code  used  tc  describe  a  commodity  or 
group  of  commodities  for  rating  and  billing  purposes. 
Also  see:  COMMODITY  CODE  QUALIFIER  (23) 

Reference  Designator (s) :  AC05  E607  GA07  L503 

PRO  3  PR04  IK  03  1R04 

1R05  1 R  06  1R07  TD104 

TF301  TF302  9T02  W203 

NO  1 1  1  W041  1 


23  COMMODITY  CODE  QUALIFIER 

(Spec:  Type  =  A  Min  =  1;  Max  =  1) 

Qualifier  for  the  commodity  coding  system  used  to 
define  the  item  lading  description  (see  Appendix  A- 
A6  thru  Al  3  ,  A33) 

CODE  DEFINITION 

A  SCHEDULE  A,  tariff  schedules  of  the 

United  States  annocated 

3  U. S.  foreign  trade  SCHEDULE  B,  statistical 

classification  of  domestic  and  foreign 
commodities  exported  form  the  United  States 
C  Canadian  freight  classification 

E  coordinated  motor  freight  classification 

G  Canadian  wheat  board,  grain  code  for 

terminal  elevator  accounting 
H  Brussels  nomenclature  harmonized  system 

{harmonized  3TN) 

I  MUST  AMP 


L  last  contained  contents  STCC 

M  mutually  defined 

N  national  motor  freight  classification  (NMFC) 

S  standard  international  trade  classification 

(SI  TC) 

T  standard  transportation  commodity  code  (STCC) 

U  uniform  freight  classification  (DFC) 

Also  see:  COMMODITY  CODE  (22) 

Reference  Designator (s)  :  GA01  L5G4  1RQ2  TD103 

ST 03  W0110  K0410 


26  COUNTRY  CODE 

(Spec:  Type  =  A  Min  =  2;  Max  =  2) 

Two  character  ISC  standard  country  code 
(See  Appendix  A-A5) 

Reference  Designator (s)  :  1404  D704  D904  E404 

E3001  F40  4  F704  FS04 

N404  NAM  09  R405  R6  19 
S405  S905  U  404  US04 

V907  X107k 


65  HEIGHT 

(Spec:  Type  =  D2  Min  =  1:  Max  =  6) 

Vertical  dimension  of  an  olject  measured  when  the 
object  is  in  the  upright  position. 

Also  see:  LENGTH  (3 2f 

MEASUREMENT  UNIT  QJALIFIEF  (90) 

WIDTH  (189) 

UNIT  OF  MEASUREMENT  CODE  (355) 
Reference  Designator (s) :  G39Q7  L403  P0415 


66  IDENTIFICATION  CODE  QUALIFIER 

(Spec:  Type  =AN  Min  =  1;  Max  =  2) 

Type  of  identification  code: 

CODE  DEFINITION 

1  DUNS 

2  SCAC 

3  FMC 

4  IATA 

5  SIRET 

6  Mutually  defined 

7  DOCK 

8  Vendor  UPC  code 

9  DUNS  with  4  digit  suffix  (UCS  uses 

only  CCDS  9 f 

A  Automotive  Industry  Action  Group(AIAG) 

Reference  Designator (s)  :  A1101  A1  203  A1205  C105 

Q.202  C40  1  D 102  D503 

1102  F102  F503  F0108 

E0  806  F0911  N  1 0  3  Q407 

Si  03  S809  U 10 2  U502 


67  IDENTIFICATION  CODE 

(Spec:  Type  =AN  Min  =  2;  Max  =17) 

DUNS.  SCAC.  FMC.  SIRET.  IATA.  UPC.  DUNS  with 


suffix-  mutually  defined  or  DOCK  code  (See 
Appendix  A- A2 ,  A16,  A17,  A18) 

Note:  DCS  uses  only  DUNS  with  suffix. 

Also  see:  IDENTIFICATION  CODE  QUALIFIER  (66) 

Reference  Designator (s)  :  A1102  A1204  A1206  C106 

C203  C402  D 103  D504 

E1Q3  F 10  3  F504  F0109 

F0602  F  06  03  F0807  F0912 
N104  Q408  S 1 04  S810 

U103  0503 


81  WEIGHT 

(Spec:  Type  =N  Min  =  1  ;  Max  =  8) 

Numeric  Value  of  Weight 

Also  see:  WEIGHT  QUALIFIER  (187) 

WEIGHT  UNIT  QUALIFIER  (188) 

UNIT  OF  MEASUREMENT  CODE  (355) 

Reference  D esignator (s)  :  CTT03  F0401  F0404  G505 

G0503  G2004  G3103  G3901 
G7603  GD105  ISS03  L004 
1301  L80  3  M 803  K1105 

N703  Q20  7  Q402  TD107 

TD305  80206  W0209  W0302 
"fi  1 2 1 0  W 1 2  1 3  H2004  W2106 
W2109  W2507  W2510  W2802 
W7602 


82  LENGTH 

(Spec:  Type  =D2  Min  =  1;  Max  =6) 

largest  Horizontal  Dimension  of  an  Object 
measured  when  the  object  is  in  the  upright 
position. 

Also  see:  HEIGHT  (65) 

MEASUREMENT  UNIT  QUALIFIER  (90) 
WIDTH  (189) 

UNIT  OF  MEASUREMENT  CODE  (355) 
Reference  Designator (s)  :  G3909  L40 1  P0413 


93  NAME 

(Spec:  Type  =AN  Min  =  1;  Max  =  35) 

Free-form  organization  name  or  official  title 
as  it  should  appear  for  mailing  address 

Reference  Designator  (s)  :  G303  G6102  N102  N201 

N202  NAM 02  S808  SCH05 
2T01  U  6 1 0  2 


TBANSACTIG N  SET  #365 


This  appendix  contains  the  transaction  set,  shown  as  it 
would  be  in  the  EDI  Data  Set  documenta ti on .  This  trans¬ 
action  set  is  required  for  the  data  transmission  described 
in  Chapter  IV. 


365  UNIT  MOVEMENT  DATA 

ABSTRACT:  This  transaction  set  is  used  by  the  sender  to  transmit 
unit  movement  data  to  other  joint  deployment  community  members. 

Require-  flan  loop  loop 
iient  Use  ID  loser 

ST  TRANSACTION  SET  HEADER 
PURPOSE:  To  indicate  the  start  of  a  transaction  set  and  to 
assign  a  control  number 


'  ST 0 1  M3  1 

1 ST02  329  1 

*  Transaction ^ 

'Transaction  1 

l  * 

1  Set  ID  !  * 

1  Set  Control  1 

1  A01  | 

1  Number  i 

1  n  AN  03/03  j 

|  M  AN  04/09 1 

17  Characters  maximum  length 


M  1  0  Q 

"A01"  is  a  special  process  used 
in  tne  EDI  interface  software  to 
process  the  set  ID.  version,  £ 
functional  ID. 


BGF  BEGINNING  SEGMENT  FOR  FILE  TRANSFER  INFORMATION 
PURPOSE:  To  transmit  identifying  numbers,  dates,  and  other 
basic  data  relating  to  the  transaction  set. 


1  1 

!  | 

1  BGF01  128  1 

1  1 

1 BGF02  127  * 

1 

1 

M  1  D  0 

1  1 
_  BGF |  * 

1  1 

1  Reference  1 

1  1 
Reference  | 

N 

1 

1 

1  1 

|No.  Qual  | 

Number 

1  1 

L 

1 

1 _ 1 _ 

|  «  AN  02/02  | 

1  n  AN  01/22  1 

J 

31  Characters  maximum  length 


365  UNIT  MOVEMENT  DATA 


Seoul rf-  na>  loop  loop 

nont  Use  10  InOf* 


N1  NAME 

PURPOSE:  To  identify  a  party  by  type  of  organization,  name  and  code 


T“ 

1 

1 N1 01 

1 

98  1 

I 

1 N1 02  931  1 

1  1  t 

M  2  0  0 

I 

» 

1 

l 

.Organi 

1 

zation^  * 

i  1  1 

1  Name  | *  | 

1 

j  Identifier  | 

1  i  1 

The  type  of  organization  to  which 

1_ 

|  H  AN 

01/22 1 

|  C  AN  01/35)  | 

the  name  is  applied  is  specified 

py  a  two  character  code.  The 
definition  for  data  element  90 

contains  the  code  list. 

r~ 

i 

1 N1 03 

i 

661 

1 

*N104  67*  1 

1  1  1 

I 

i  * 

1  1 

1  ID  Code  |  * 

,  Qualifier 

,  ID  Code  ,  N  | 

,  PQ304  ,  ,  , 

When  N103-N1D4  are  not  used. 

N102  (name)  is  required. 

1  1  P0304  1 

1 

i 

1 

|  |  C  AN  01/02) 

_lL 

AN  02/1?) 

J 

63  Characters  maximum  length 


N2  ADDITIONAL  NAME  INFORMATION 
PURPOSE:  To  specify  additional  name:  or  those  longer  than  35 
characters  in  length 


1  1 

1  N2Q 1  93 1 

1 N2Q2  931 

~ 1 

0  2  0  0 

1  1 

1  N2  |  - 

1  1 

j  Name  ^  * 

1  1 

Name 

1  1 

Ni 

Li 

This  is  a  required  segment  if 
additional  information  is 
required  to  completely  specify 

1 _ 1 _ 

)  r,  AN  01/35) 

)  0  AN  01/35) 

_ 1 

the  name. 

75  Cnaracters  maximum 

length 

365  UNIT  MOVEMENT  DATA 


Beouire-  Am  loop  loop 
"nit  list  10  lnopx 


D1  UNIT  IDENTIFICATION 

PURPOSE:  To  specify  unit  identification  code  (UIC) 
and  additional  unit  information 


I  I  I 

i 01  r  i 


D101  1111  1 D1 02  1 46 1 

1  1  T  1 

UIC  | -  t  Type  I 

UMD 


I  I  H  AN  06/06]  I  M  AN  01/01 1 

r5To4  i?5  *0105  lUT1 

I  City  I  I  I 

I  Name  I  I  I 

I  (Station)  I  I  I 

I  0  AS  02/19 1  |  c  ft  02/02 1 

65  characters  maximum  length 


D 1 03  93' 

I 

Name  |  * 

0  AN  01/35; 

□106  26 1 

Country  N 
Cede  |  L 

C  ft  D2/02 1 


□2  EQUIPMENT  DETAILS 

PURPOSE:  To  provide  equipment  information 


D201  122 

Line 

Item 

Number 

n  fiN  06/06 


D204  24'  1 D205  64 

....  I  I  VA/ator 


'□202  324 

1 D2D3  532 

«  Load 

■  Line 

'  Number 

1  Index 

1 

1  Number 

|  0  ftN  01/Q1 

|  n  N  02/02 

M  1  0 


Uhen  D 1 04  not 
used.  D105-D106 
not  used 


C  1D0Q  0  0 


Model 

Number 


Water  * 
Commodity  I 

Code  I 


D206  216 

Type 

Packing 


Note:  Mandatory  when 
1  I  coae  in  segment  N101 

|  |  is  JO  (=Joint 

„  Deployment  ftgency); 
optional  otneruise 


$ 

& 

1 D207  91 

1 

N 

1  Mode 

| 

L 

1  n  a  oi/oi 

29  characters  maximum  length 


D3  EQUIPMENT  MEASUREMENT 

PURPOSE:  To  describe  physical  dimensions 


1  1  1 D301  372 1  1 D302  82*  1 D3D3  1 89 1  1  C  1000  0  0 

'nJ  *  Item  1  '  *  * 

I  1*1  Description  I  “  I  Length  j  M  |  Width  |  "  | 

III  /j  /j  |j  Note:  This  data 

I  |  I  II  AN  01/02  I  I  C  N  01/05  I  I  C  02  01/06  i  i  se?nent  squired  if 

1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1  cooe  in  segment  N101 

_  . _ ^ is  JD;  optional 

1 D3D4  65*  '  D305  90* 1 D306  QV 1  otherwise 

I  I  1  'I  II 

1  '  Moacni'omont  I  I  I 


I  Height 


Measurement 
I  Unit  I 
i  Qualifier  t 


C  02  01/06  |  |  c  A  01/01 


Weight 


H  N  01/09 


D307  188 1  1 D308  183*  'D309  184 


Weight  I 
Unit  I 

Qualifier  I 
n  a  oi/oi  i 


Volume 


|  11  A  01/01  |  |  n  N  01/08 

58  characters  maximum  length 


I  I  Volume  I N I 
1*1  Unit  lLl 

I  I  Qualifier  I  I 
I  i  n  a  oi/oi  i  i 


365  UNIT  MOVEMENT  DATA 


Require-  Rex  loop  loop 

nent  Use  10  Inoex 


04  CARGO  INFORMATION 
PURPOSE:  To  provide  cargo  information 


1 — 1 

1  1 D401 

413  1 

'0402  414  1 

— I 

1  1  l 

*4  Cargo  „ 

1  1 
Heavy 

N  1 
| 

1 

1  1  Cateqory  1 

1  Lift  1 

L 

1 

1  1  Code  1 

1  Code  1 

1 

1 _ ] 

l_u: _ 

AN  03/03  1 

|  M  AN  01/01  | 

_ 1 

C  1  0  0 

Note.  This  data  segment  is  required 
if  code  m  segment  N101  is  JD 
(=Joint  Deployment  Agency): 
optional  for  others 


04  characters  maximum  length 


APPENDIX  C 

AUTOMATED  UNIT  EQUIPMENT  LISTINGS  (AUELS) 

This  appendix  contains  Automated  Unit  Equipment 
Listings.  The  data  in  these  listings  was  used  in  the  demon¬ 
stration  of  the  EDI  concept,  as  described  in  Chapter  IV.  It 
should  be  noted  that,  although  these  two  listings  contain 
data  from  different  units  {Ft.  Meade  and  Ft.  Ord),  the  data 
from  both  was  transmitted  in  one  transaction  set  as  shown  in 
Figure  4.3. 


Copy  avaCabla  to  DTIC  ao«» 

permit  fully  lepible  reproduction 
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